Re: [PATCH] org-agenda.el: Add a M-, binding for org-priority-show

2021-05-01 Thread Adam Spiers
On Sat, 1 May 2021 at 11:45, Bastien  wrote:
> Kyle Meyer  writes:
> > With a C-u, org-agenda-priority calls org-priority-show.  So perhaps
> > instead of adding a new binding, the documentation should be improved.
>
> I pushed a small enhancement for org-agenda-priority's docstring
> with commit e080eb759.
>
> I am reluctant adding another keybinding to the agenda especially
> since there is no keybinding for `org-priority-show'.

Thanks, that sounds like a better approach.



Re: Can no longer org-set-link-parameters with "fuzzy" link types

2021-04-06 Thread Adam Sneller
Thank you both for the replies!

Nicholas - can you recommend how to best implement this with 
font-lock-add-keywords?

Best regards,

-Adam

> On 6 Apr 2021, at 13:06, Nicolas Goaziou  wrote:
>
> Hello,
>
> Kyle Meyer  writes:
>
>> [ Sorry for the slow response. ]
>>
>> Adam Sneller writes:
>>
>>> I have a function that searches for broken fuzzy links in org-mode and
>>> applies org-warning face to anything it finds:
>>>
>>> (org-link-set-parameters
>>> "fuzzy"
>>> :face (lambda (path)
>>> (let ((org-link-search-inhibit-query t))
>>> (if (condition-case nil
>>> (save-excursion
>>> (save-match-data
>>> (org-link-search path (point) t)))
>>> (error nil))
>>> 'org-link 'org-warning
>>>
>>> In 9.4.4 this patch breaks this:
>>>
>>> https://code.orgmode.org/bzg/org-mode/commit/8c4e270df280a08b7e61295712c86246088146ba
>>>
>>> Is there some other recommended way to get this done as of 9.4.4?
>>
>> I don't know enough about the change to say whether this is recommended,
>> but it looks like you could get the behavior you're after with something
>> like
>>
>>  (add-to-list 'org-link-parameters
>>   '("fuzzy" :face (lambda (path) ...)))
>
> Link parameters are meant to be used with "scheme:path" links. However,
> we forbid internal link types, as writing [[fuzzy:whatever]] would be
> confusing for Org. As a consequence, link parameters are not meant to
> control internal links.
>
> We might need a different variable specific to internal links, but in
> the current case, using `font-lock-add-keywords' should be sufficient.
>
> Regards,
> --
> Nicolas Goaziou


Re: overloading of internal priority calculations in agenda

2021-03-09 Thread Adam Spiers
Thanks Jack for the helpful response and support of my assessment.

I do intend to fix this as part of my ongoing (but currently delayed)
work on improving agenda sorting and adding an option to manually sort.

On Tue, 9 Mar 2021 at 07:07, Jack Kamm  wrote:
>
> Hi Adam,
>
> > I further noticed that this overloading of the internal priority by
> > including timestamp and habit data causes disruption to the behaviour
> > I imagine most users would expect from `org-agenda-sorting-strategy'.
> > For example, if you have `priority-down' as the first entry in the
> > `agenda' section and `category-keep' as the second, then differences
> > in the SCHEDULED timestamp are included in the priority calculation
> > and can therefore prevent sorting of two adjacent [#B] items by
> > category.  This seems like a bug to me, or at least breaks the
> > Principle of Least Surprise.
>
> I just ran into this issue you highlight here.
>
> In particular, I was trying to set the org-agenda-sorting-strategy to
>
> (priority-down scheduled-down)
>
> i.e., sorting by priority (highest first), and then within priority,
> sorting by scheduled (most recent first).
>
> However, the fact that the priority includes the scheduled timestamp
> makes this sorting strategy impossible.
>
> I agree this seems like a bug, in that it contradicts the written
> documentation as far as I can tell (for example, the *Help* for
> org-agenda-sorting-strategy mentions nothing of the fact that the
> priority includes the scheduled timestamp, and I don't see anything
> about it in the *Info* either).
>
> I imagine that many have gotten used to the default behavior of sort by
> highest priority, then by earliest scheduled timestamp, but we could
> keep this default behavior by adding "scheduled-up" after
> "priority-down" in org-agenda-sorting-strategy, as you allude.
>
> Jack



Can no longer org-set-link-parameters with "fuzzy" link types

2021-02-24 Thread Adam Sneller
I have a function that searches for broken fuzzy links in org-mode and applies 
org-warning face to anything it finds:

(org-link-set-parameters
"fuzzy"
:face (lambda (path)
(let ((org-link-search-inhibit-query t))
(if (condition-case nil
(save-excursion
(save-match-data
(org-link-search path (point) t)))
(error nil))
'org-link 'org-warning

In 9.4.4 this patch breaks this:

https://code.orgmode.org/bzg/org-mode/commit/8c4e270df280a08b7e61295712c86246088146ba

Is there some other recommended way to get this done as of 9.4.4?

Thanks,

Adam Sneller – CCO
MS2 Digital
20 Old Bailey, St Paul's, ​London EC4M 7AN
​adam.sneller@ms2.digital
office: 020 3988 6800
direct: 020 3988 6809
The information in this e-mail and any documents and files transmitted with it 
are confidential and for the use of the intended recipient only. If you are not 
the intended recipient, please delete the message and any attachments 
immediately and notify the sender. Although MS2 Group Limited believes this 
e-mail and any attachments are free of any virus or other defect which may 
affect a computer, it is the responsibility of the recipient to ensure that it 
is virus free and MS2 Group Limited does not accept any responsibility for any 
loss or damage arising from its use. MS2 Group Limited is registered in England 
and Wales, company number 10410414. Registered office: 27 Old Gloucester 
Street, London WC1N 3AX. 'MS2 Digital' is the trading name of MS2 Group Limited.
​
​© 2020 MS2 Group Limited


Re: Citations with page numbers using helm-bibtex and org-ref

2021-02-21 Thread Adam Sneller
Thanks John!

I think you have just given me my next homework assignment for "Adam's list of 
things to noodle around with in eLisp" :)

Adam

> On 21 Feb 2021, at 17:40, John Kitchin  wrote:
>
> It seems like some ideas are getting mixed up in your description. A cite 
> link in org-ref is related to a bibtex entry in a bibtex file, not to an org 
> heading in an org-file. In other words in your example, I would expecta 
> bibtex entry with the key bradley1973es to exist in one of the default 
> bibliography files you use (or in the one you define in a bibliography link). 
> The notes are just for your purposes.
>
> the headings/links in your notes file will not show up in any completion 
> backend in org-ref for citation selection, as only the bibtex entries are 
> used to construct those.
>
>  If you are looking for a way to select one of those headings from your 
> notes, and then insert the appropriate link, you would have to use something 
> different than org-ref. there is not presently a way to map an annotated cite 
> link to the specific note. I am not even sure you can write a function that 
> does that, as the functions only take a key for looking up the note file, and 
> not the description too. It certainly is possible to write a new function 
> that would work on the link at point to do that, and to call it 
> interactively, or add it as an action though. You would still get the key to 
> open the note file, and then use the link description if it exists to somehow 
> search forward for the relevant heading or text, failing gracefully if you, 
> for example, make a cite to a page you did not make a note on.
>
> When it comes time to authoring a paper, I think the workflow is you would 
> have to open the notes you made, find the section you want to use in your 
> paper, and copy the link you put in your notes to your new document. There 
> are some variations you might consider, but none of them would really be 
> integrated into the org-ref completion mechanisms that are generated from the 
> bibtex entries.
>
> For example you  might store the link or parts in a property like this:
>
> * The Accelerator-Multiplier Model
>   :PROPERTIES:
>   :key:  bradley1973es
>   :page: p200
>   :cite: [[cite:bradley1973es][p200]]
>   :END:
>
>
> and then write a small function you use interactively to copy it, e.g.
>
> #+BEGIN_SRC emacs-lisp
> (defun get-link ()
>   (interactive)
>   (kill-new (org-entry-get (point) "cite")))
> #+END_SRC
>
> and you might bind that to a key if you use it a lot. Alternatively you might 
> put the key in file-level property, and only store the page, and use property 
> inheritance, to build the link. There are a lot of options to choose from. 
> But, simply copying and pasting a link might also be the simplest.
>
> It might be possible to use the org-store/insert-link machinery for this too, 
> but I have found that to be trickier than I thought it should be in the past.
>
> John
>
> ---
> Professor John Kitchin
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu <http://kitchingroup.cheme.cmu.edu/>
>
>
>
> On Sun, Feb 21, 2021 at 12:13 PM Adam Sneller  <mailto:a...@earth2adam.com>> wrote:
> Hi Bruce/John,
>
> Thanks for getting back to me. So I guess your notes file would look 
> something like this?
>
>
> #+TITLE: Bradley, J. (1973): Essential Mathematics For Economists
>
> * Dynamic models: the consumption function
> [[cite:bradley1973es][p164]]
>
> * Changes in Capital Stock
> [[cite:bradley1973es][p188]]
>
> * The Accelerator-Multiplier Model
> [[cite:bradley1973es][p200]]
>
>
> So when when it comes time to author your paper, if you run org-store-link on 
> any of these, the description gets stripped off the link, so that only 
> cite:bradley1973es is stored (which obviously defeats the purpose). And if 
> you copy the link over by hand, it maps back to the document bradley197es.org 
> <http://bradley197es.org/> (not the actual note).
>
> Am I missing anything?
>
> Adam
>
>> On 21 Feb 2021, at 12:21, Bruce D'Arcus > <mailto:bdar...@gmail.com>> wrote:
>>
>> On Sat, Feb 20, 2021 at 10:31 PM Adam Sneller > <mailto:adam.sneller@ms2.digital>> wrote:
>>
>>> I currently use org-ref and helm-bibtex to manage my database of academic 
>>> sources, with one notes file per source. A lot of my sources are books. So 
>>> note typically grow over time, as I add multiple headers (each pertaining 
>

Re: Citations with page numbers using helm-bibtex and org-ref

2021-02-21 Thread Adam Sneller
Hi Bruce/John,

Thanks for getting back to me. So I guess your notes file would look something 
like this?


#+TITLE: Bradley, J. (1973): Essential Mathematics For Economists

* Dynamic models: the consumption function
[[cite:bradley1973es][p164]]

* Changes in Capital Stock
[[cite:bradley1973es][p188]]

* The Accelerator-Multiplier Model
[[cite:bradley1973es][p200]]


So when when it comes time to author your paper, if you run org-store-link on 
any of these, the description gets stripped off the link, so that only 
cite:bradley1973es is stored (which obviously defeats the purpose). And if you 
copy the link over by hand, it maps back to the document bradley197es.org 
<http://bradley197es.org/> (not the actual note).

Am I missing anything?

Adam

> On 21 Feb 2021, at 12:21, Bruce D'Arcus  wrote:
>
> On Sat, Feb 20, 2021 at 10:31 PM Adam Sneller  
> wrote:
>
>> I currently use org-ref and helm-bibtex to manage my database of academic 
>> sources, with one notes file per source. A lot of my sources are books. So 
>> note typically grow over time, as I add multiple headers (each pertaining to 
>> a chapter or topic/note taken from that source).
>>
>> But now I want to produce a citation that references the page numbers where 
>> I captured that note...
>>
>> What is the recommended way to handle this? Are you breaking notes into 
>> individual files, each with their own @inbook citation?
>
> Generally speaking, referencing page numbers and sections of a cited
> source is not handled by dedicated citations, but rather by
> annotations on the containing citation (book etc.).
>
> So in the pandoc syntax, for example, [@book, p23].
>
> I do the same with notes, and just included the specific citation with
> the note if I need to maintain the specific source page.
>
> Bruce
>



Citations with page numbers using helm-bibtex and org-ref

2021-02-20 Thread Adam Sneller
I currently use org-ref and helm-bibtex to manage my database of academic 
sources, with one notes file per source. A lot of my sources are books. So note 
typically grow over time, as I add multiple headers (each pertaining to a 
chapter or topic/note taken from that source).

But now I want to produce a citation that references the page numbers where I 
captured that note...

What is the recommended way to handle this? Are you breaking notes into 
individual files, each with their own @inbook citation? And suppose you are 
capturing a section (not necessarily a chapter title). Are you still using 
@inbook?

Thanks!

Adam Sneller – CCO
MS2 Digital
20 Old Bailey, St Paul's, ​London EC4M 7AN
​adam.sneller@ms2.digital
office: 020 3988 6800
direct: 020 3988 6809
The information in this e-mail and any documents and files transmitted with it 
are confidential and for the use of the intended recipient only. If you are not 
the intended recipient, please delete the message and any attachments 
immediately and notify the sender. Although MS2 Group Limited believes this 
e-mail and any attachments are free of any virus or other defect which may 
affect a computer, it is the responsibility of the recipient to ensure that it 
is virus free and MS2 Group Limited does not accept any responsibility for any 
loss or damage arising from its use. MS2 Group Limited is registered in England 
and Wales, company number 10410414. Registered office: 27 Old Gloucester 
Street, London WC1N 3AX. 'MS2 Digital' is the trading name of MS2 Group Limited.
​
​© 2020 MS2 Group Limited


Re: Auto-activate new <<>>

2021-02-08 Thread Adam Sneller
Thanks John! It looks like there is also an org-activate-target-links which may 
narrow the field a bit. Here is what I have so far:

(defadvice org-activate-target-links (after ad-update-target-links ())
  "Activate radio target links as soon as a new target is created."
  (lambda ()
(interactive)
(when (and (org-in-regexp org-target-regexp)
   (not (org-in-regexp org-target-regexp nil t)))
  (org-update-radio-target-regexp
(ad-activate 'org-activate-target-links)

Unfortunately, this is not working for me...

Any ideas?

> On 8 Feb 2021, at 13:44, John Kitchin  wrote:
>
> I guess the place to do it is with an advice on org-activate-links. Maybe a 
> simple after advice would do.
>
> John
>
> ---
> Professor John Kitchin
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu <http://kitchingroup.cheme.cmu.edu/>
>
>
>
> On Sun, Feb 7, 2021 at 8:48 PM Kyle Meyer  <mailto:k...@kyleam.com>> wrote:
> Adam Sneller writes:
>
> > I want to call org-update-radio-target-regexp as soon as org-mode
> > recognises a new <<>> has been created (which seems to
> > happen as soon as the third ">" is typed).
> >
> > What hook can I use to get this done?
>
> I'm not spotting any hook that could be used for this.  The <<>>
> fontification happens through a simple 'regular expression => face'
> mapping in org-font-lock-keywords.
>
> You're probably aware of this and it's just not as automatic as you'd
> like, but just in case: pressing `C-c C-c' with point on <<>
> will call org-update-radio-target-regexp.
>



Auto-activate new <<>>

2021-02-07 Thread Adam Sneller
I want to call org-update-radio-target-regexp as soon as org-mode recognises a 
new <<>> has been created (which seems to happen as soon as the 
third ">" is typed).

What hook can I use to get this done?

Adam Sneller – CCO
MS2 Digital
20 Old Bailey, St Paul's, ​London EC4M 7AN
​adam.sneller@ms2.digital
office: 020 3988 6800
direct: 020 3988 6809
The information in this e-mail and any documents and files transmitted with it 
are confidential and for the use of the intended recipient only. If you are not 
the intended recipient, please delete the message and any attachments 
immediately and notify the sender. Although MS2 Group Limited believes this 
e-mail and any attachments are free of any virus or other defect which may 
affect a computer, it is the responsibility of the recipient to ensure that it 
is virus free and MS2 Group Limited does not accept any responsibility for any 
loss or damage arising from its use. MS2 Group Limited is registered in England 
and Wales, company number 10410414. Registered office: 27 Old Gloucester 
Street, London WC1N 3AX. 'MS2 Digital' is the trading name of MS2 Group Limited.
​
​© 2020 MS2 Group Limited


Re: overloading of internal priority calculations in agenda

2020-12-22 Thread Adam Spiers
Thanks a lot - appreciate the feedback!

On Tue, 22 Dec 2020 at 23:38, Samuel Wales  wrote:

> if my opinion is worth anything [perhaps not much here :]], i like
> your proposals and the idea of being able to re-sort an existing
> agenda assuming that is your goal.
>
> i don't use any priority sorting except in user-customizable but it
> makes sense to decouple them for those who do.  and i frequently want
> to differently sort an existing agenda view.
>
>
> On 12/22/20, Adam Spiers  wrote:
> > Hi again,
> >
> > On Wed, Dec 02, 2020 at 02:20:53PM +, Adam Spiers wrote:
> >>Hi all,
> >>
> >>I'm currently working on adding a feature to org-agenda which allows
> >>manual ordering of entries in combination with the existing automatic
> >>ordering (as dictated by `org-agenda-sorting-strategy').
> >>
> >>During my investigations I noticed that while `org-get-priority' converts
> >>[#B] style cookies into a numeric priority which is a multiple of
> >>1000, further adjustments are made in functions like
> >>`org-agenda-get-scheduled' before adding this numeric priority as a
> >>text property on the entry:
> >>
> >>'priority (if habitp (org-habit-get-priority habitp)
> >>(+ 99 diff (org-get-priority item)))
> >>
> >>In this case `diff' refers to the number of days between now and when
> >>the item was scheduled.  A slightly different calculation is made in
> >>`org-agenda-get-timestamps':
> >>
> >>(org-add-props item props
> >>  'priority (if habit?
> >>(org-habit-get-priority (org-habit-parse-todo))
> >>  (org-get-priority item))
> >>
> >>I further noticed that this overloading of the internal priority by
> >>including timestamp and habit data causes disruption to the behaviour
> >>I imagine most users would expect from `org-agenda-sorting-strategy'.
> >>For example, if you have `priority-down' as the first entry in the
> >>`agenda' section and `category-keep' as the second, then differences
> >>in the SCHEDULED timestamp are included in the priority calculation
> >>and can therefore prevent sorting of two adjacent [#B] items by
> >>category.  This seems like a bug to me, or at least breaks the
> >>Principle of Least Surprise.
> >
> > [snipped]
> >
> >>Given that `org-agenda-sorting-strategy' now supports all manner of
> >>sorting criteria, many of which are time-sensitive, I would like to
> >>know if there is any reason not to remove this overloading of the
> >>priority calculation, i.e. decoupling it to depend purely on the
> >>result of `org-get-priority' and `org-habit-get-priority'?
> >>
> >>If fact, perhaps we could go one step further and add support for new
> >>habit-priority-{up,down} sorters to `org-agenda-sorting-strategy', so
> >>that the priority-{up,down} sorters sort purely by the priority cookie
> >>and nothing else?
> >
> > Gently bumping this as I didn't get any replies yet.  I would like to
> > continue working on a solution, but obviously don't want to waste time
> > on something which would be rejected.
> >
> > If it is considered important to preserve the exact behaviour
> > currently offered by `org-agenda-sorting-strategy' then I would
> > propose the following:
> >
> > - Keep the existing priority-{up,down} which combine priority cookies
> >with timestamp data and the result from `org-habit-get-priority',
> >but probably also deprecate it and remove it from the default value.
> >
> > - Introduce new priority-cookie-{up,down} sorters which operate purely
> >on [#A] and [#1] style priority cookies and nothing else.
> >
> > This would facilitate decoupling of the sortable criteria whilst
> > remaining backwards compatible.
> >
> > Does this sound reasonable?  I am keen to proceed very soon (ideally
> > over the Xmas break).  I have already written some new ert tests for
> > `org-agenda-sorting-strategy' which would be included in any submitted
> > patches.
> >
> > Thanks!
> > Adam
> >
> >
>
>
> --
> The Kafka Pandemic
>
> Please learn what misopathy is.
>
> https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
>


Re: overloading of internal priority calculations in agenda

2020-12-22 Thread Adam Spiers

Hi again,

On Wed, Dec 02, 2020 at 02:20:53PM +, Adam Spiers wrote: 

Hi all,

I'm currently working on adding a feature to org-agenda which allows 
manual ordering of entries in combination with the existing automatic 
ordering (as dictated by `org-agenda-sorting-strategy'). 

During my investigations I noticed that while `org-get-priority' converts 
[#B] style cookies into a numeric priority which is a multiple of 
1000, further adjustments are made in functions like 
`org-agenda-get-scheduled' before adding this numeric priority as a 
text property on the entry: 


   'priority (if habitp (org-habit-get-priority habitp)
   (+ 99 diff (org-get-priority item)))

In this case `diff' refers to the number of days between now and when 
the item was scheduled.  A slightly different calculation is made in 
`org-agenda-get-timestamps': 


   (org-add-props item props
 'priority (if habit?
   (org-habit-get-priority (org-habit-parse-todo))
 (org-get-priority item))

I further noticed that this overloading of the internal priority by 
including timestamp and habit data causes disruption to the behaviour 
I imagine most users would expect from `org-agenda-sorting-strategy'. 
For example, if you have `priority-down' as the first entry in the 
`agenda' section and `category-keep' as the second, then differences 
in the SCHEDULED timestamp are included in the priority calculation 
and can therefore prevent sorting of two adjacent [#B] items by 
category.  This seems like a bug to me, or at least breaks the 
Principle of Least Surprise. 


[snipped]

Given that `org-agenda-sorting-strategy' now supports all manner of 
sorting criteria, many of which are time-sensitive, I would like to 
know if there is any reason not to remove this overloading of the 
priority calculation, i.e. decoupling it to depend purely on the 
result of `org-get-priority' and `org-habit-get-priority'? 

If fact, perhaps we could go one step further and add support for new 
habit-priority-{up,down} sorters to `org-agenda-sorting-strategy', so 
that the priority-{up,down} sorters sort purely by the priority cookie 
and nothing else? 


Gently bumping this as I didn't get any replies yet.  I would like to 
continue working on a solution, but obviously don't want to waste time 
on something which would be rejected. 

If it is considered important to preserve the exact behaviour 
currently offered by `org-agenda-sorting-strategy' then I would 
propose the following: 


- Keep the existing priority-{up,down} which combine priority cookies
  with timestamp data and the result from `org-habit-get-priority',
  but probably also deprecate it and remove it from the default value.

- Introduce new priority-cookie-{up,down} sorters which operate purely
  on [#A] and [#1] style priority cookies and nothing else.

This would facilitate decoupling of the sortable criteria whilst 
remaining backwards compatible. 

Does this sound reasonable?  I am keen to proceed very soon (ideally 
over the Xmas break).  I have already written some new ert tests for 
`org-agenda-sorting-strategy' which would be included in any submitted 
patches. 


Thanks!
Adam



overloading of internal priority calculations in agenda

2020-12-02 Thread Adam Spiers

Hi all,

I'm currently working on adding a feature to org-agenda which allows
manual ordering of entries in combination with the existing automatic
ordering (as dictated by `org-agenda-sorting-strategy').

During my investigations I noticed that while `org-get-priority' converts
[#B] style cookies into a numeric priority which is a multiple of
1000, further adjustments are made in functions like
`org-agenda-get-scheduled' before adding this numeric priority as a
text property on the entry:

'priority (if habitp (org-habit-get-priority habitp)
(+ 99 diff (org-get-priority item)))

In this case `diff' refers to the number of days between now and when
the item was scheduled.  A slightly different calculation is made in
`org-agenda-get-timestamps':

(org-add-props item props
  'priority (if habit?
(org-habit-get-priority (org-habit-parse-todo))
  (org-get-priority item))

I further noticed that this overloading of the internal priority by
including timestamp and habit data causes disruption to the behaviour
I imagine most users would expect from `org-agenda-sorting-strategy'.
For example, if you have `priority-down' as the first entry in the
`agenda' section and `category-keep' as the second, then differences
in the SCHEDULED timestamp are included in the priority calculation
and can therefore prevent sorting of two adjacent [#B] items by
category.  This seems like a bug to me, or at least breaks the
Principle of Least Surprise.

I did some git archaelogy and found that the first ever git commit
4be4c562 (for release 4.12a) already includes
`org-agenda-sorting-strategy', but at that point, time-{up,down} were
the only time-related sorting criteria available.

I was also wondering where the magic 99 number above came from, and I
found that the same (first ever) commit introduced the following
priority calculation:

(+ (- 5 diff) (org-get-priority txt))

Subsequently, commit 70b6cc5d (for release 5.10a) changes this to:

(+ 94 (- 5 diff) (org-get-priority txt))

and then commit 69ec6258 (on 2016-11-25) changes it to

(+ 99 diff (org-get-priority item))

Given that `org-agenda-sorting-strategy' now supports all manner of
sorting criteria, many of which are time-sensitive, I would like to
know if there is any reason not to remove this overloading of the
priority calculation, i.e. decoupling it to depend purely on the
result of `org-get-priority' and `org-habit-get-priority'?

If fact, perhaps we could go one step further and add support for new
habit-priority-{up,down} sorters to `org-agenda-sorting-strategy', so
that the priority-{up,down} sorters sort purely by the priority cookie
and nothing else?

Thanks!
Adam



[PATCH] org-agenda.el: Add a M-, binding for org-priority-show

2020-12-01 Thread Adam Spiers
This offers an easy way to check the internal numeric priority
used for sorting within the agenda.
---
 doc/org-manual.org | 8 
 lisp/org-agenda.el | 1 +
 2 files changed, 9 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 5a84a6de6..e914af42d 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -9891,6 +9891,14 @@ the other commands, point needs to be in the desired 
line.
   Set tags for the current headline.  If there is an active region in
   the agenda, change a tag for all headings in the region.
 
+- {{{kbd(M-\,)}}} (~org-priority-show~) ::
+
+  #+kindex: M-,
+  #+findex: org-priority-show
+  Show the numeric priority for the current item.  This priority is
+  composed of the main priority given with the =[#A]= cookies, and by
+  additional input from the age of a schedules or deadline entry.
+
 - {{{kbd(\,)}}} (~org-agenda-priority~) ::
 
   #+kindex: ,
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index a482b3db4..40ea31fdc 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -2399,6 +2399,7 @@ (defun org-agenda-mode ()
 (org-defkey org-agenda-mode-map "\C-c\C-p" #'org-agenda-previous-date-line)
 (org-defkey org-agenda-mode-map "\C-c," #'org-agenda-priority)
 (org-defkey org-agenda-mode-map "," #'org-agenda-priority)
+(org-defkey org-agenda-mode-map [(meta ?,)] #'org-priority-show)
 (org-defkey org-agenda-mode-map "i" #'org-agenda-diary-entry)
 (org-defkey org-agenda-mode-map "c" #'org-agenda-goto-calendar)
 (org-defkey org-agenda-mode-map "C" #'org-agenda-convert-date)
-- 
2.28.0




Re: [ANN] org-ql 0.5 released

2020-11-23 Thread Adam Porter
Hi Jean Louis,

Thanks for your feedback.

>As the more complexities are created then even org-ql becomes complex
>to work with just as SQL becomes more and more complex with more
>relational tables and pieces of information.

The idea of Org QL is to make such things simple.  For example, you
don't need to know Elisp to run "M-x org-ql-search RET" and type this
query:

  todo: priority:A deadline:to=3

Which would display all to-do items with priority A due within the next
3 days.

> For org-ql I hope that your system can be used as underlying layer or
> low level language for functionality that may help user to think their
> stuff without thinking on underlying functionality. You have offered
> examples and those are in my opinion too abstract for Org users. They
> are fine for programmers or more skilled users.

The org-ql-search and org-ql-view UIs are built on the underlying org-ql
library.

> High level functions would be something like a wizard with code
> generation, that creates hyperlink for the user without user having to
> think about org-ql

> It could be something like `ql-meta' or `ql-summary' that is created
> on the fly and that collects information for agenda like view, and
> creates Org file with hyperlink that invokes the agenda like view.

This is already implemented.  Search views can be built incrementally
using the Transient UI.  See the screencast GIFs in the readme.

> Entries from the past week could be something on the fly. Additional
> hyperlink in the ql-summary could have the user to customize sorting
> without thinking of the underlying code.

See "M-x org-ql-view-recent-items RET".

> Find entries matching a certain CUSTOM_ID could be automatically
> generated heading:
>
> *** Entries by CUSTOM_ID
>
> ONE TWO THREE MORE HYPERLINKED AND SORTED CUSTOM_IDS
>
> when user clicks on any of those this would invoke the org-ql and show
> those entries. By click and by thinking, not necessarily by
> constructing the org-ql.
>
> Similar could be for deadlines.

This is already implemented.  See the sections "Links" and "Dynamic
Blocks" in the readme.

> Music could be sorted by author in the summary Org file that has many
> hyperlinks which in turn use the org-ql to activate music, or annotate
> it.

Those are interesting ideas for future work, thanks.

> Your file `examples.org' has some hyperlinks under the heading
> Contents and none of hyperlinks work. Why is it so?

I went to https://github.com/alphapapa/org-ql/blob/master/examples.org
and clicked the links in "Contents" and they work for me.

> In the end I could not test examples as it asks for org-ql-search that
> in turn asks for super-agenda that I do not have.
>
> I wonder how could I install the package that requires
> org-super-agenda and that it starts working. Maybe you missed one
> (require 'org-super-agenda) as when I wish to install it, it does not.

If you install org-ql from MELPA or with Quelpa, org-super-agenda will
be installed automatically.  The `require' function does not install
packages.

Thanks,
Adam




[ANN] Org QL Custom Predicates Tutorial

2020-11-22 Thread Adam Porter
Hi again friends,

Following the release of org-ql 0.5, I've pushed a new feature to the
0.6-pre branch: custom predicates.  You can now easily define custom
predicates to make searching easier.  For example, you could define a
custom (person) predicate like so:

#+BEGIN_SRC elisp
(org-ql-defpred person (name)
  "Search for entries with the \"person\" property being NAME."
  :body (property "person" name))
#+END_SRC

Then you could do a search for entries in your agenda files having the
property "person" with the value "Bob" like this:

#+BEGIN_SRC elisp
(org-ql-search (org-agenda-files) "person:Bob")
#+END_SRC

Please see the tutorial for a walkthrough of the process of building a
custom predicate incrementally:

https://github.com/alphapapa/org-ql/blob/master/examples/defpred.org

Thanks,
Adam




[ANN] org-ql 0.5 released

2020-11-22 Thread Adam Porter
Hi friends,

FYI, I've released org-ql 0.5.  It includes many improvements since the
last release, including some unique features, such as linking to and
bookmarking agenda-like views for easy access, and designing agenda-like
views incrementally with a Magit-like UI.

Changelog: https://github.com/alphapapa/org-ql#05

Please let me know if you have any feedback.

Thanks,
Adam




[ANN] org-super-agenda 1.2 released

2020-11-21 Thread Adam Porter
Hi friends,

FYI, I've released version 1.2 of org-super-agenda, which includes
several improvements since the last stable release.

https://github.com/alphapapa/org-super-agenda#changelog

Please let me know if you have any feedback.

Thanks,
Adam




[ANN] org-ql: Bookmarks, dynamic blocks, and links

2020-11-11 Thread Adam Porter
Hi all,

FYI, I've recently added some new features to org-ql[0]:

1.  Dynamic Blocks[1] allow you to insert a block that lists headings in
a document which match a query, formatting them into certain columns.
For example (please excuse the wrapped header line for this message):

#+BEGIN: org-ql :query "todo: priority:A,B" \
:columns (todo (priority "P") deadline heading) \
:sort (deadline priority) :take 7 :ts-format "%Y-%m-%d %H:%M"
| Todo | P | Deadline | Heading   |
|--+---+--+---|
| TODO | A | 2017-07-07 00:00 | Take over the world   |
| TODO | B | 2017-07-10 00:00 | Renew membership in supervillain club |
| TODO | A | 2017-07-15 00:00 | Take over the universe|
| TODO | B | 2017-07-21 00:00 | Internet  |
| TODO | A | 2017-08-01 00:00 | Spaceship lease   |
| TODO | A |  | Skype with president of Antarctica|
| TODO | B |  | Take over Mars|
#+END:

2. Links[2] allow you to access an Org QL View by clicking on a link,
like:

[[org-ql-search:todo:NEXT priority:A]]

It integrates with the Org link storing and inserting commands (`C-c l`
and `C-c C-l`), so you can easily create a custom search view and insert
a link to it into an Org file.  Then you can click the link to run the
search.

3.  Bookmarks allow Org QL View buffers to be bookmarked with Emacs
bookmark commands, like "C-x r m".  This also integrates with my new
buffer/window/frame/workspace-restoration package, Burly.[3]

Together, these features allow agenda-like views and searches to be
easily and quickly designed, saved, and accessed.

Please let me know if you have any feedback.

Thanks,
Adam

0: https://github.com/alphapapa/org-ql
1: https://github.com/alphapapa/org-ql#dynamic-block
2: https://github.com/alphapapa/org-ql#links
3: https://github.com/alphapapa/burly.el




Re: [PATCH] org-refile.el: Add org-refile-reverse which toggles org-reverse-note-order

2020-11-09 Thread Adam Spiers

On Sun, Sep 06, 2020 at 02:10:09AM -0400, Amin Bandali wrote:

Bastien writes:


Hi Adam,

Adam Spiers  writes:


This is useful for prepending to the start of the target headline
instead of appending to the end, or vice-versa depending on
org-reverse-note-order.


I think this would be useful.  What others think?


[...]

+1; sounds quite useful to me as well.

Thank you both.


Is it time to revisit this yet?

Thanks!



[PATCH] x11idle: Make installation a little smoother

2020-10-25 Thread Adam Spiers
Fix a -Wimplicit-int compiler warning, and make it more obvious how to
obtain scrnsaver.h on three of the most popular Linux distros.

Signed-off-by: Adam Spiers 
---
 contrib/scripts/x11idle.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/contrib/scripts/x11idle.c b/contrib/scripts/x11idle.c
index 22cefe1e6..b8db27560 100644
--- a/contrib/scripts/x11idle.c
+++ b/contrib/scripts/x11idle.c
@@ -1,4 +1,9 @@
+/* This header file is provided by the libxss-dev package on Debian,
+ * by the libXss-devel rpm on openSUSE, and the libXScrnSaver-devel
+ * rpm on Fedora.
+ */
 #include 
+
 #include 
 
 /* Based on code from
@@ -7,7 +12,7 @@
  * compile with 'gcc -l Xss x11idle.c -o x11idle' and copy x11idle into your
  * path
  */
-main() {
+int main() {
 XScreenSaverInfo *info = XScreenSaverAllocInfo();
 //open the display specified by the DISPLAY environment variable
 Display *display = XOpenDisplay(0);
-- 
2.28.0




Re: [PATCH] [WIP] org-agenda.el: Make org-entries-lessp more efficient

2020-10-24 Thread Adam Spiers
On Sat, Oct 24, 2020 at 01:36:05PM +0200, Bastien wrote: 
Hi Adam, 

this looks good to me, thanks a lot. 


Thanks for the review :-) 

Does "WIP" means that you want to wait for other patches to complete 
this one or shall I apply this one already? 


The intention is for it to be a standalone patch, so I don't think 
there's any need to wait for other patches.  The "WIP" was coming more 
from the fact that I haven't done extensive testing to make sure I 
didn't break a single one of the many sorting criteria - especially 
this one:


+('category-keep   (if (org-cmp-category a b) +1 nil)) ;; FIXME: check this

Ideally there would already be unit and/or functional tests covering 
agenda sorting, but I can't see any and I imagine they would be 
non-trivial to add (although perhaps not too difficult either). 

Also, the previous behaviour was to silently ignore 
user-defined-{up,down} if org-agenda-cmp-user-defined was not defined, 
but that intuitively felt wrong to me (IMHO it kind of violates the 
Principle of Least Surprise) so I didn't bother to preserve that 
behaviour.  However I admit that is a pretty subjective choice, so if 
you think the existing behaviour should be preserved, I can tweak the 
code to do that.  In fact, even if you agree with me that it would be 
better to generate an error when user-defined-{up,down} is used with 
org-agenda-cmp-user-defined being nil, I just noticed that it currently 
generates the very unhelpful error: 


org-entries-cmp-1: Symbol’s function definition is void: nil

so we would want to explicitly catch that case and generate a more 
helpful error message, e.g. "org-agenda-sorting-strategy contains 
user-defined sorting but org-agenda-cmp-user-defined is nil". 

BTW, as you can partially see from the below link, I did some 
performance profiling relating to this change and it did indeed seem 
to shave a few milliseconds off org-entries-lessp, although in the 
grand scheme of things, that didn't make as much of a dent in 
org-agenda's running time as I'd hoped for ;-) 



https://gist.github.com/trishume/40bf7045a23412d4c016f5e8533437db#gistcomment-3494087



[PATCH] [WIP] org-agenda.el: Make org-entries-lessp more efficient

2020-10-18 Thread Adam Spiers
[This is only lightly tested and therefore probably not quite ready
for merging yet; however I'm submitting now to get feedback.]

org-entries-lessp was not as efficient a multi-criteria comparator as
it could have been, since it evaluated all criteria and then combined
them via (eval (cons 'or ...)), thereby missing a chance for lazy
evaluation via short-circuiting: if one of the earlier criteria in
org-agenda-sorting-strategy-selected evaluates to non-nil, giving a
definitive comparison result, there is no need to evaluate any of the
later criteria.

So instead iterate over the criteria one by one, and return as soon as
we have a definitive result.

Also remove code duplication by adopting a unified approach to
ascending/descending sorting.

Note that the way org-entries-lessp is invoked by
org-agenda-finalize-entries is still inefficient, because the same
values (e.g. timestamps, priorities, etc.) are extracted from every
pair of entries in each comparison within the sort.  In the future,
introducing a Schwartzian transform can probably address this.

However the refactoring in this commit is a step in the right
direction, and it also allows other code to determine which comparison
is decisive in ordering any two elements.

Signed-off-by: Adam Spiers 
---
 lisp/org-agenda.el | 103 -
 1 file changed, 46 insertions(+), 57 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 88bb3f90d..eadc7fedd 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -7187,65 +7187,54 @@ (defsubst org-cmp-habit-p (a b)
 (cond ((and ha (not hb)) -1)
  ((and (not ha) hb) +1
 
+(defun org-entries-cmp (a b)
+  "Iterate through the sorting criteria in
+`org-agenda-sorting-strategy-selected' until a sorter returns a
+definitive comparison, then return a cons cell (RESULT . SORTER)."
+  (let (sorted-by
+   sort-result
+   (ss org-agenda-sorting-strategy-selected))
+(while (and ss (not sorted-by))
+  (let* ((sorter (car ss))
+(sorter-name (symbol-name sorter))
+;; If sorter symbol ends in "-down" then pass the -up version
+;; to org-entries-cmp-1 and then negate the result.
+(sorter-down-p (string-match "-down\\'" sorter-name))
+(up-sorter
+ (if sorter-down-p
+ (replace-regexp-in-string "-down\\'" "-up" sorter-name)
+   sorter-name)))
+   (setq sort-result (org-entries-cmp-1 a b (intern up-sorter)))
+   (setq ss (cdr ss))
+   (when sort-result
+ (setq sort-result (if sorter-down-p (- sort-result) sort-result))
+ (setq sorted-by sorter
+(cons sort-result sorted-by)))
+
+(defun org-entries-cmp-1 (a b sorter)
+  "Compare two entries via the given sorter."
+  (pcase sorter
+('timestamp-up(org-cmp-ts a b ""))
+('scheduled-up(org-cmp-ts a b "scheduled"))
+('deadline-up (org-cmp-ts a b "deadline"))
+('tsia-up (org-cmp-ts a b "timestamp_ia"))
+('ts-up   (org-cmp-ts a b "timestamp"))
+('time-up (org-cmp-time a b))
+('stats-up(org-cmp-values a b 'org-stats))
+('priority-up (org-cmp-values a b 'priority))
+('effort-up   (org-cmp-effort a b))
+('category-up (org-cmp-category a b))
+('category-keep   (if (org-cmp-category a b) +1 nil)) ;; FIXME: check this
+('tag-up  (org-cmp-tag a b))
+('todo-state-up   (org-cmp-todo-state a b))
+('habit-up(org-cmp-habit-p a b))
+('alpha-up(org-cmp-alpha a b))
+('user-defined-up (funcall org-agenda-cmp-user-defined a b
+
 (defun org-entries-lessp (a b)
   "Predicate for sorting agenda entries."
-  ;; The following variables will be used when the form is evaluated.
-  ;; So even though the compiler complains, keep them.
-  (let* ((ss org-agenda-sorting-strategy-selected)
-(timestamp-up(and (org-em 'timestamp-up 'timestamp-down ss)
-  (org-cmp-ts a b "")))
-(timestamp-down  (if timestamp-up (- timestamp-up) nil))
-(scheduled-up(and (org-em 'scheduled-up 'scheduled-down ss)
-  (org-cmp-ts a b "scheduled")))
-(scheduled-down  (if scheduled-up (- scheduled-up) nil))
-(deadline-up (and (org-em 'deadline-up 'deadline-down ss)
-  (org-cmp-ts a b "deadline")))
-(deadline-down   (if deadline-up (- deadline-up) nil))
-(tsia-up (and (org-em 'tsia-up 'tsia-down ss)
-  (org-cmp-ts a b "timestamp_ia")))
-(tsia-down   (if tsia-up (- tsia-up) nil))
-(ts-up   (and (org-em 'ts-up 'ts-down ss)
-  (org-cmp-ts a b "timestamp")))
-(ts-dow

[PATCH] org-agenda.el: Fix 'Maker' typo

2020-10-18 Thread Adam Spiers
TINYCHANGE

Signed-off-by: Adam Spiers 
---
 lisp/org-agenda.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index a1b20649d..88bb3f90d 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -4127,7 +4127,7 @@ (defvar org-agenda-last-marker-time (float-time)
 
 (defun org-agenda-new-marker ( pos)
   "Return a new agenda marker.
-Maker is at point, or at POS if non-nil.  Org mode keeps a list of
+Marker is at point, or at POS if non-nil.  Org mode keeps a list of
 these markers and resets them when they are no longer in use."
   (let ((m (copy-marker (or pos (point)) t)))
 (setq org-agenda-last-marker-time (float-time))
-- 
2.28.0




Re: variable-pitch-mode misaligns org-mode heading tags

2020-09-16 Thread Adam Spiers
On Wed, Sep 16, 2020 at 11:55:53PM +0100, Adam Spiers wrote: 
I've actually managed it get it working now!  See the attached patch. 
However unfortunately it is not ready to be merged yet.  Firstly, it 
breaks `test-org/tag-align'.  Secondly, since this changes the method 
of alignment from simply using raw spaces to using a single space with 
a display text property, when the file is saved and reloaded, it just 
displays a single space and the alignment is lost.  Another 
unfortunate side-effect is that if the file is simultaneously 
displayed in a graphical window and a text window via the same emacs 
server (e.g. via emacsclient -t), then one of the two windows will 
have incorrect alignment. 

So I think the correct fix will be to keep the original number of 
spaces, but use a display text property to redisplay those spaces as a 
single space with the given width.  I'm guessing that the display text 
property will be ignored on text-only (tty) windows, fixing both 
problems in one go. 

So I'll take another stab at this soon, if Bastien or some other Org 
guru can confirm I'm on the right track. 


Hrm, no this isn't good enough.  For graphical windows we still need 
to set the display text properties to align all tags when the buffer 
initially loads.  AFAICS there's currently no code to trigger this, so 
it would need to be added, and for large files this might actually 
cause problems with file loading time unless it was done in the 
background (a bit like fontification can be done). 

Advice on how to handle this best is very welcome. 



Re: Help administer code.orgmode.org: moderate user access and manage the gogs instance

2020-09-16 Thread Adam Spiers
On Wed, 16 Sep 2020 at 08:21, Bastien  wrote:
> Hi Timothy,
>
> TEC  writes:
>
> >> Is anyone willing to help with (1) and/or (2)?
> >
> > I'm willing to give (2), and potentially (1) a shot :)
>
> Thanks a lot!  I wrote you offlist about this.

It's not nearly as generous an offer, but as I don't have a gogs
account yet, I volunteer to be a guinea pig if TEC wants to practice
giving (1) a shot ;-)

I think I used to have push access to Worg many years ago, and I've
noticed one or two issues which I'd be happy to fix if I regained
that.  Or is Worg also subject to a peer review process these days?

Cheers,
Adam



Re: variable-pitch-mode misaligns org-mode heading tags

2020-09-16 Thread Adam Spiers
On Wed, Sep 16, 2020 at 03:03:02PM -0400, Jeff Filipovits wrote: 
It looks like (window-text-pixel-size) could be used to calculate the 
pixel length of the tags list? 


Ahah!  This indeed did the trick!  I have no idea how I missed this 
handy function previously when I was scouring the manual... 

I am having trouble deciphering the 
manual (https://www.gnu.org/software/emacs/manual/html_node/elisp/Pixel-Specification.html#Pixel-Specification) 
for pixel specification for spaces, though. The right alignment 
specification for some reason sends the tags to the next line, as do 
most other solutions that I would expect to align the text to the 
right side of the window. 

I can experiment more in a couple days, but in the meantime maybe 
someone smarter than me give some hints on how to use the pixel 
specification properties. 


I've actually managed it get it working now!  See the attached patch. 
However unfortunately it is not ready to be merged yet.  Firstly, it 
breaks `test-org/tag-align'.  Secondly, since this changes the method 
of alignment from simply using raw spaces to using a single space with 
a display text property, when the file is saved and reloaded, it just 
displays a single space and the alignment is lost.  Another unfortunate 
side-effect is that if the file is simultaneously displayed in a graphical 
window and a text window via the same emacs server (e.g. via emacsclient -t), 
then one of the two windows will have incorrect alignment. 

So I think the correct fix will be to keep the original number of 
spaces, but use a display text property to redisplay those spaces as a 
single space with the given width.  I'm guessing that the display text 
property will be ignored on text-only (tty) windows, fixing both 
problems in one go. 

So I'll take another stab at this soon, if Bastien or some other Org 
guru can confirm I'm on the right track. 

BTW I tried your code and for some reason it didn't insert any space 
for me, but I didn't look into that yet. 


The way it’s written it would only reduce the gap between the headline 
and tags to a space, and it assumes there are multiple spaces there 
already. If there’s no space between the two, I don’t think it’ll 
insert one. Probably not the best way as it was thrown together to 
test the text property fix. 


I figured out that it wasn't working because my `org-tags-column' is a 
negative value in order to align flush-right, and your code didn't 
support that. 

I accepted long ago that the solution to using a variable pitch font 
for org headings was that the tags would not be aligned to the right 
and never looked back, so maybe this is not worth the price of fixing 
it if it is messy. And diving down to calculating the pixel width of 
text seems like it’s getting pretty messy. 


Actually I think it ended up fairly clean.  Huge thanks to you for 
giving me the hint I needed!  I just adapted your code a bit.  I've 
marked you as a co-author in the commit message.  For now your 
contribution probably still falls into the category of "Tiny changes": 


https://orgmode.org/worg/org-contribute.html#org9fbb342

However you might want to preemptively sign the copyright assignment 
papers: 


https://orgmode.org/worg/org-contribute.html#copyrighted-contributors
>From 7655c32847d7abd9da7603b1a1a314b7d1b87ba5 Mon Sep 17 00:00:00 2001
From: Adam Spiers 
Date: Wed, 16 Sep 2020 23:12:04 +0100
Subject: [PATCH] [WIP] org.el: Align tags using specified space display property
To: emacs-orgmode@gnu.org

Previously tags on heading lines were aligned using spaces, which
assumed a fixed width font.  However variable pitch fonts are becoming
increasingly popular, so ensure there is always a single space in
between the heading text and the (colon-delimited) list of tags, and
then if necessary use a display text property to specify the exact
width required by that space to align it in accordance with the value
of `org-tags-column' which the user has chosen:

  https://www.gnu.org/software/emacs/manual/html_node/elisp/Pixel-Specification.html#Pixel-Specification

If the value is positive, align flush-left; if negative, align
flush-right; and if zero, just leave a normal width space.

See the following links for the discussion threads leading to this
patch:

- https://lists.gnu.org/archive/html/emacs-orgmode/2020-09/msg00415.html
- https://gitlab.com/protesilaos/modus-themes/-/issues/85

Signed-off-by: Adam Spiers 
Co-authored-by: Jeff Filipovits 
---
 lisp/org.el | 68 ++---
 1 file changed, 39 insertions(+), 29 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 053635c85..e800eb642 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -11831,35 +11831,45 @@ (defun org-toggle-tag (tag  onoff)
   res)))
 
 (defun org--align-tags-here (to-col)
-  "Align tags on the current headline to TO-COL.
-Assume point is on a headline.  Preserve point when aligning
-tags."
-  (when (org-mat

Re: variable-pitch-mode misaligns org-mode heading tags

2020-09-16 Thread Adam Spiers

Hi Jeff,

Firstly thanks a lot for looking into this! 


On Tue, Sep 15, 2020 at 01:41:04PM -0400, Jeff Filipovits wrote:
Following the call for help to fix bugs, and with building guilt, I’ve 
taken a stab at fixing aligning tags when using a variable-pitch font. 
I haven’t tested this much because I do not know if it is misguided, 
but it seems to work. 

Seems the only way to do it is to use the ‘display text property and 
expand a single space between the headline and tags. Here is a drop-in 
replacement of org--align-tags-here which ensures there is one space 
between the tags and headline, and then expands that space by setting 
a text property. 


Yes, this is the same conclusion I reached a little while ago: 


   https://gitlab.com/protesilaos/modus-themes/-/issues/85#note_407147422

However as mentioned there, AFAICS this approach only manages to 
*left*-align the tags, not *right*-align them.  When there are several 
tags, this can be problematic as the colon-delimited list of tags will 
either spill over the buffer's right margin, or avoid that by 
requiring an alignment column which is further to the left and ends up 
interfering with the main text of the buffer.  Given that the 
colon-delimited lists have variable numbers of characters, I think 
it's clear that right alignment is the only decent space-efficient 
layout.


BTW I tried your code and for some reason it didn't insert any space for 
me, but I didn't look into that yet. 

I’ve removed the point-preserving code because it does not seem to be 
needed using this method. This would also allow removing 
org-fix-tags-on-the-fly from org-self-insert-command since there is 
only a single space between the headline and the tags and it is 
adjusted automatically. 


Makes sense. 

If this looks promising I can throw some more time at it. If not, I 
will happily abandon it. 


I think it's promising for sure.  But I think there is still a 
remaining problem regarding how to implement the right alignment of 
the colon-delimited list of tags.  If this list uses a fixed-width 
font then it is relatively easy, because then the value to provide to 
:align-to can be calculated as `org-tags-column' minus the column 
width of the tag list.  And indeed this seems to be how the original 
version of `org--align-tags-here' achieves right alignment: 


   (new (max (if (>= to-col 0) to-col
   (- (abs to-col) (string-width (match-string 1

But the whole point of this exercise is to support variable-width 
fonts.  In this case, the correct position for the end of the single 
space is most likely not even a multiple of the fixed column width, so 
it would probably need to be measured in pixels rather than columns. 
And in order to calculate it, it is first necessary to calculate the 
exact width in pixels of the colon-delimited list of tags. 

As I mentioned in the comment linked above, I searched for a way of 
calculating the pixel width of the tag list, and the best I could find 
was `pos-visible-in-window-p' which has some issues which I mentioned 
there.  If you have thoughts on whether I'm right about those, and if 
so how to solve them, I'd love to hear! 


Cheers,
Adam



Re: [feature request] org-at-timestamp-p should accept multiple parameters

2020-09-09 Thread Adam Faryna
Thanks. I understand now.

I think to generate a patch in this case it's too much hustle, for a minor
benefit.

--
Adam

On Wed, 9 Sep 2020 at 09:13, Bastien  wrote:

> Hi Adam,
>
> Adam Faryna  writes:
>
> > Ok, maybe I misunderstood the purpose of this function. I wanted to
> > use it to check if the timestamp is active or inactive and I tried to
> > get it by using (org-at-timestamp-p 'inactive) while pointing at the
> > timestamp. But actually when I call it on any timestamp like
> > [2020-09-04 Fri], <2020-09-04 Fri> I always get nil. So either it's a
> > bug, or I miss something.
>
> (org-at-timestamp-p) returns t on an active timestamp.
>
> (org-at-timestamp-p 'inactive) returns t on any timestamp, including
> inactive ones.
>
> If you think the docstring could be enhanced, can you share a patch?
>
> See https://orgmode.org/worg/org-contribute.html on how to contribute.
>
> Thanks,
>
> --
>  Bastien
>


Re: [feature request] org-at-timestamp-p should accept multiple parameters

2020-09-08 Thread Adam Faryna
Ok, maybe I misunderstood the purpose of this function. I wanted to use it
to check if the timestamp is active or inactive and I tried to get it by
using (org-at-timestamp-p 'inactive) while pointing at the timestamp. But
actually when I call it on any timestamp like [2020-09-04 Fri], <2020-09-04
Fri> I always get nil. So either it's a bug, or I miss something.

Thanks,

Adam

On Tue, 8 Sep 2020 at 15:26, Bastien  wrote:

> Hi Adam,
>
> thanks, but I still need to understand the exact change you suggest
> and what general fix/improvement it will provide.  Probably a patch
> will be easier to understand for this.
>
> Thanks,
>
> --
>  Bastien
>


Re: [feature request] org-at-timestamp-p should accept multiple parameters

2020-09-08 Thread Adam Faryna
I think the problem is general. If you work with any timestamp that is
agenda like, you can't check using this function if it's active or
inactive. The one solution would be to remove parameter "agenda" and
consider every timestamp as a agenda like (the "timestamp" in "
org-at-timestamp-p" suggest that there is time information in it anyway) by
default, or keep it as it is but extend parameter list with support of
named parameters where agenda-like can be activated with :agenda t,
inactive timestamp with :inactive t, with default values nil.

Thanks,
Adam

On Sat, 5 Sep 2020 at 13:59, Bastien  wrote:

> Hi Adam,
>
> you forgot to copy the emacs-orgmode list - can you repost your email
> there?
>
> Thanks,
>
> --
>  Bastien
>


Re: make org-refile auto-recache when needed?

2020-09-05 Thread Adam Spiers

Hi Bastien,

On Fri, Sep 04, 2020 at 04:12:08PM +0200, Bastien wrote:

Adam Spiers  writes:

I note that when org-refile-use-cache is enabled and the cache becomes
stale, attempting to refile results in this error message (originating
from `org-refile-check-position'):

Invalid refile position, please clear the cache with `C-0 C-c C-w' before 
refiling

Is there any reason why it couldn't just automatically rebuild the
cache when needed?


If we can rebuild the cache for refile target in a reliable way, sure,
we should do this.  I had a quick look and this isn't straightforward,
so help is welcome.  I note the idea for after 9.4.


Thanks for the reply!

I don't see why we need to be able to rebuild it reliably.  Can't we
just try, then if it succeeds, refile as normal, and if it fails, then
output an error saying that the cache rebuild failed and making a
helpful suggestion of what to try next?  Maybe I'm missing something.



Re: [PATCH] doc: Document C-. for jumping to today when choosing a timestamp

2020-09-05 Thread Adam Spiers

On Fri, Sep 04, 2020 at 03:47:08PM +0200, Bastien wrote:

Hi Adam,

Adam Spiers  writes:


This useful key binding was previously missing from the manual.


Thanks for spotting this.  I added it (as 2df7a8fa) together with
the `.'  keybinding, which achieves the same.


Thanks Bastien.  There's actually a subtle but important difference
between the two: when editing a timestamp with a time of day in, e.g.

<2020-08-27 Thu 17:00>

then the prompt in the minibuffer will be:

SCHEDULED Date+time [2020-08-27]: 17:00

While the point is after the "17:00", pressing '.' does not cause a
jump to today's date; instead it just appends the '.' character after
the "17:00".  In contrast, C-. successfully jumps to today without
altering the prompt input.  So in this context, C-. is far more useful
than just '.'.

Funnily enough I found that if I first jump to the beginning of
"17:00" via C-a, then they do indeed behave identically.



Re: time-warping - retroactively marking DONE?

2020-08-29 Thread Adam Spiers
On Wed, 8 Jul 2020 at 23:09, No Wayman  wrote:
> I emailed Adam directly with an experimental package I wrote to
> solve the problem of changing the todo-state of an entry at an
> arbitrary time.
> He suggested I posted here as well:
>
> https://github.com/progfolio/epoch/
>
> The package advises current-time to return `epoch-current-time' if
> is set (falling back to the usual current-time if not).
> A macro, `epoch-with-time' is provided which allows a body to be
> executed with current-time set to an arbitrary time.
> Two commands (which I may separate into their own package),
> `epoch-todo' and `epoch-agenda-todo' call their respective
> org-mode commands.
> `org-read-date' is called with the tasks's SCHEDULED or DEADLINE
> time pre-populated so one can easily edit relative to that time.
>
> Still very much a work in progress, but the two commands are
> useful for me so far.
>
> Any ideas, suggestions, criticisms are appreciated.

Many thanks again for this.  It's working great for me!

In case anyone's interested, here's my use-package config (which uses
the awesome straight.el package manager to install it):

https://github.com/aspiers/emacs/blob/aa62bd84b51a02cb0fc980862a63514349d253bf/.emacs.d/init.d/as-org-mode.el#L111-L116

I agree with your observation that it might be nicer to separate out
the org-specific stuff into a separate package, because the epoch
stuff seems useful in its own right outside org-mode.



[PATCH] org-refile.el: Add org-refile-reverse which toggles org-reverse-note-order

2020-08-29 Thread Adam Spiers
This is useful for prepending to the start of the target headline
instead of appending to the end, or vice-versa depending on
org-reverse-note-order.
---
 doc/org-manual.org | 10 ++
 etc/ORG-NEWS   |  9 +
 lisp/org-keys.el   |  1 +
 lisp/org-refile.el | 11 +++
 4 files changed, 31 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 3eb745b5d..e499367b7 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -7190,6 +7190,16 @@ special command:
   Copying works like refiling, except that the original note is not
   deleted.
 
+- {{{kbd(C-c C-M-w)}}} (~org-refile-reverse~) ::
+
+  #+kindex: C-c C-M-w
+  #+findex: org-refile-reverse
+  Works like refiling, except that it temporarily toggles how the
+  value of ~org-reverse-note-order~ applies to the current buffer.  So
+  if ~org-refile~ would append the entry as the last entry under the
+  target header, ~org-refile-reverse~ will prepend it as the first
+  entry, and vice-versa.
+
 ** Archiving
 :PROPERTIES:
 :DESCRIPTION: What to do with finished products.
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 10658a970..a3c8397fc 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -267,6 +267,15 @@ Source code block header argument =:file-mode= can set file
 permissions if =:file= argument is provided.
 
 ** New commands
+*** ~org-refile-reverse~
+
+Use default keybinding == to run command
+~org-refile-reverse~.  It is almost identical to ~org-refile~, except
+that it temporarily toggles how ~org-reverse-note-order~ applies to
+the current buffer.  So if ~org-refile~ would append the entry as the
+last entry under the target heading, ~org-refile-reverse~ will prepend
+it as the first entry, and vice-versa.
+
 *** ~org-table-header-line-mode~
 
 Turn on a minor mode to display the first data row of the table at
diff --git a/lisp/org-keys.el b/lisp/org-keys.el
index 37df29983..902651175 100644
--- a/lisp/org-keys.el
+++ b/lisp/org-keys.el
@@ -582,6 +582,7 @@ (define-key org-mode-map (kbd "") #'org-shifttab)
 (org-defkey org-mode-map (kbd "C-c ;") #'org-toggle-comment)
 (org-defkey org-mode-map (kbd "C-c C-w") #'org-refile)
 (org-defkey org-mode-map (kbd "C-c M-w") #'org-refile-copy)
+(org-defkey org-mode-map (kbd "C-c C-M-w") #'org-refile-reverse)
 (org-defkey org-mode-map (kbd "C-c /") #'org-sparse-tree) ;minor-mode reserved
 (org-defkey org-mode-map (kbd "C-c \\") #'org-match-sparse-tree) ;minor-mode r.
 (org-defkey org-mode-map (kbd "C-c RET") #'org-ctrl-c-ret)
diff --git a/lisp/org-refile.el b/lisp/org-refile.el
index 7eb0a9643..c6ff35535 100644
--- a/lisp/org-refile.el
+++ b/lisp/org-refile.el
@@ -384,6 +384,17 @@ (defun org-refile-copy ()
 
 (defvar org-capture-last-stored-marker)
 
+;;;###autoload
+(defun org-refile-reverse ( arg default-buffer rfloc msg)
+  "Invoke `org-refile', but temporarily toggling how
+~org-reverse-note-order~ applies to the current buffer.  So if
+`org-refile' would append the entry as the last entry under the
+target heading, ~org-refile-reverse~ will prepend it as the first
+entry, and vice-versa."
+  (interactive "P")
+  (let ((org-reverse-note-order (not (org-notes-order-reversed-p
+(org-refile arg default-buffer rfloc msg)))
+
 ;;;###autoload
 (defun org-refile ( arg default-buffer rfloc msg)
   "Move the entry or entries at point to another heading.
-- 
2.27.0




[PATCH] doc: Document C-. for jumping to today when choosing a timestamp

2020-08-29 Thread Adam Spiers
This useful key binding was previously missing from the manual.

Signed-off-by: Adam Spiers 
---
 doc/org-manual.org | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 3eb745b5d..7c291c3a7 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -6028,6 +6028,7 @@ calendar, or by pressing {{{kbd(RET)}}}, the date 
selected in the
 calendar is combined with the information entered at the prompt.  You
 can control the calendar fully from the minibuffer:
 
+#+kindex: C-.
 #+kindex: <
 #+kindex: >
 #+kindex: M-v
@@ -6041,6 +6042,7 @@ can control the calendar fully from the minibuffer:
 #+kindex: M-S-LEFT
 #+kindex: RET
 #+attr_texinfo: :columns 0.25 0.55
+| {{{kbd(C-.)}}}   | Jump to today. |
 | {{{kbd(RET)}}}   | Choose date at point in calendar.  |
 | {{{kbd(mouse-1)}}}   | Select date by clicking on it. |
 | {{{kbd(S-RIGHT)}}}   | One day forward.   |
-- 
2.27.0




Bug: org-agenda-sorting-strategy priority has no effect [9.3.7 (9.3.7-16-g521d7f-elpaplus @ /Users/devil/.emacs.d/elpa/org-plus-contrib-20200803/)]

2020-08-05 Thread Adam Faryna
09) (:endgroup))
 org-modules '(ol-w3m ol-bbdb ol-bibtex ol-docview ol-gnus ol-info ol-irc 
ol-mhe ol-rmail ol-eww
   org-habit org-drill org-collector org-depend org-eww 
org-checklist)
 org-shiftup-final-hook '(windmove-up)
 org-ascii-headline-spacing '(1 . 1)
 org-blocker-hook '(org-block-todo-from-children-or-siblings-or-parent 
org-depend-block-todo)
 org-export-creator-string "Adam Faryna (appdy.net)"
 org-odt-preferred-output-format "doc"
 org-mode-hook '(#[0 "\301\211\207" [imenu-create-index-function 
org-imenu-get-tree] 2]
 (closure
  (org-agenda-skip-regexp org-table1-hline-regexp
   org-table-tab-recognizes-table\.el org-table-dataline-regexp
   org-table-any-border-regexp 
org-agenda-restriction-lock-overlay
   org-agenda-overriding-restriction org-agenda-diary-file
   org-complex-heading-regexp calendar-mode-map t)
  nil (setq imenu-create-index-function (quote 
org-imenu-get-tree)))
 org-clock-load
 (lambda nil (set (make-local-variable (quote paragraph-start)) 
"[:graph:]+$")
  (set (make-local-variable (quote paragraph-separate)) 
"[:space:]*$"))
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-show-all append local] 
5]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-babel-show-result-all 
append local] 5]
 (closure
  (org--rds reftex-docstruct-symbol org-element-greater-elements
   org-clock-history org-agenda-current-date org-with-time 
org-defdecode org-def
   org-read-date-inactive org-ans2 org-ans1 
org-columns-current-fmt-compiled
   org-clock-current-task org-clock-effort 
org-agenda-skip-function
   org-agenda-skip-comment-trees org-agenda-archives-mode 
org-end-time-was-given
   org-time-was-given org-log-note-extra org-log-note-purpose
   org-log-post-message org-last-inserted-timestamp 
org-last-changed-timestamp
   org-entry-property-inherited-from org-blocked-by-checkboxes 
org-state
   org-agenda-headline-snapshot-before-repeat 
org-capture-last-stored-marker
   org-agenda-start-on-weekday org-agenda-buffer-tmp-name 
org-priority-regexp
   org-mode-abbrev-table org-mode-syntax-table 
buffer-face-mode-face org-tbl-menu
   org-org-menu org-struct-menu org-entities org-last-state 
org-id-track-globally
   org-clock-start-time texmathp-why remember-data-file
   org-agenda-tags-todo-honor-ignore-options 
iswitchb-temp-buflist
   calc-embedded-open-mode calc-embedded-open-formula 
calc-embedded-close-formula
   align-mode-rules-list org-emphasis-alist 
org-emphasis-regexp-components
   org-export-registered-backends org-modules 
org-babel-load-languages
   org-id-overriding-file-name org-indent-indentation-per-level
   org-element-paragraph-separate ffap-url-regexp 
org-inlinetask-min-level t)
  nil
  (add-hook (quote change-major-mode-hook) (quote org-show-all) 
(quote append)
   (quote local))
  )
 (closure
  (org-src-window-setup *this* 
org-babel-confirm-evaluate-answer-no
   org-babel-tangle-uncomment-comments 
org-src-preserve-indentation
   org-src-lang-modes org-link-file-path-type 
org-edit-src-content-indentation
   org-babel-library-of-babel t)
  nil
  (add-hook (quote change-major-mode-hook) (quote 
org-babel-show-result-all)
   (quote append) (quote local))
  )
 org-babel-result-hide-spec org-babel-hide-all-hashes 
org-eldoc-load)
 org-clock-persist t
 org-export-with-smart-quotes t
 org-odt-format-drawer-function '(closure
  (hfy-user-sheet-assoc hfy-html-quote-regex 
hfy-html-quote-map
   hfy-face-to-css hfy-begin-span-handler 
hfy-end-span-handler
   archive-zip-extract 
nxml-auto-insert-xml-declaration-flag t)
  (_name contents) contents)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-mime-src-mode-hook '(org-mime-src-mode-configure-edit-buffer)
 org-reverse-note-order t
 org-priority-start-cycle-with-default nil
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-hide-block-startup t
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-bibtex-headline-format-function #[257 "\300\2

[feature request] org-at-timestamp-p should accept multiple parameters

2020-08-02 Thread Adam Faryna
Hi,

recently I was doing some customization and I needed to check if timestamp
at a point is active or inactive. That timestamp also contains an agenda
like information about reoccurring.

So I tried to use org-at-timestamp-p function for this purpose.

The problem is I needed to check if the timestamp is agenda like and
inactive or ignore the context at the same time. But org-at-timestamp-p
takes only one parameter, and I needed to give it multiple parameters,
which is not possible in the current version.

Can you amend the implementation of org-at-timestamp-p to make it accept a
list of parameters or named parameters instead of just one parameter?

Thanks,
Adam


make org-refile auto-recache when needed?

2020-07-15 Thread Adam Spiers

Hi all,

I note that when org-refile-use-cache is enabled and the cache becomes
stale, attempting to refile results in this error message (originating
from `org-refile-check-position'):

Invalid refile position, please clear the cache with `C-0 C-c C-w' before 
refiling

Is there any reason why it couldn't just automatically rebuild the
cache when needed?  If it did that then I struggle to imagine why
anyone would ever *not* want the cache enabled, because in the worst
case org-refile would just behave the same as when the cache is
disabled, and in the best case it would perform a lot faster.

Cheers,
Adam



Re: :STYLE: habit causes position in agenda view to change

2020-07-15 Thread Adam Spiers

On Tue, Jul 14, 2020 at 11:33:03PM -0400, Kyle Meyer wrote:

Adam Spiers writes:


I've noticed that adding the :STYLE: habit property to a TODO causes
its position in the agenda view to change; it jumps to the bottom of
the day.  Is there any way to prevent that?


Try customizing org-agenda-sorting-strategy (in particular, dropping
habit-down from agenda's values).


Perfect, thanks so much Kyle!



Re: Org mode for meeting minutes

2020-07-07 Thread Adam Spiers
On Thu, 31 Oct 2019 at 14:04, Christian Egli  wrote:
> Hi all
>
> I'd like to revisit a very old thread[1] where Adam Spiers asks if there
> is support in Org mode for
>
> 1. Allow *fast* production of meeting agendas and minutes, exportable in
>a good-looking legible format which non-org readers can digest.
>
> 2. Allow minutes to be taken as the meeting progresses, minimising the
>amount of work required after the meeting.
>
> 3. Allow actions to be captured and then automatically extracted into a
>simple tabulated report which clearly shows actions grouped by owner.
>
> 4. Track progress of actions *after* the minutes have been issued.

Wow, this makes me feel old! ;-)

Sorry for chiming in late - only just noticed this thread.

> He goes on to say that org mode handles (1) and (2) just fine, but he
> wasn't sure about (3) and (4).
>
> His mail is from 2008 and a lot has happened in the mean time. I would
> suggest that today (1) and (2) can be handled with normal org export or
> even pandoc. Inline tasks[2] help a lot to add, well inline tasks. For (3)
> and (4) he mentions a dynamic block that could collect all action items.
>
> I never found that dynamic block he mentions, so I hacked one up (which
> was suprisingly easy). I haven't packaged it but the gist of it is
> below:

[snip]

I have no doubt that your modern solution is much better than my ancient
hack, but just for the record, the latter can be found here:

https://github.com/aspiers/emacs/blob/master/.emacs.d/init.d/as-gtd.el#L79-L117

Thanks a lot for re-raising this and subsequently writing a very nice blog
post about it too!

Cheers,
Adam

P.S. I recently discovered an exceptionally good service to aid
with capturing information from meetings:

   https://otter.ai/

Sadly it is proprietary, and the speech recognition is sophisticated
enough that I doubt that any FLOSS alternative will appear any time
soon :-(



:STYLE: habit causes position in agenda view to change

2020-07-07 Thread Adam Spiers

Hi all,

I've noticed that adding the :STYLE: habit property to a TODO causes
its position in the agenda view to change; it jumps to the bottom of
the day.  Is there any way to prevent that?

Thanks!
Adam



time-warping - retroactively marking DONE?

2020-07-07 Thread Adam Spiers

Hi all,

I'm looking for a way to retroactively mark a task as having been done
at a previous time/date.  I know that I can just change the keyword to
DONE and then edit the timestamp, but this is tedious when it's a
repeating event, e.g.:

*** NEXT [#A] meditate 15 minutes every day
  SCHEDULED: <2020-07-06 Mon 11:30-11:50 .+1d>
  :PROPERTIES:
  :LAST_REPEAT: [2020-07-05 Sun 11:13]
  :ID:   142a639c-e06d-4d4b-ad1c-edcd0d9ba6ce
  :Effort:   0:20
  :STYLE:habit
  :END:

  - State "DONE"   from "NEXT"   [2020-07-05 Sun 10:15]
  - State "DONE"   from "NEXT"   [2020-07-04 Sat 10:30]
  - State "DONE"   from "NEXT"   [2020-07-03 Fri 10:05]
  - State "DONE"   from "NEXT"   [2020-07-02 Thu 11:15]

I forgot to mark it as done yesterday, which means that I would have
to manually edit /three/ timestamps to log the correct data: 1) the
SCHEDULED timestamp, 2) the :LAST_REPEAT: property, and 3) the state
change history.

If this is not currently possible, would it make sense to write a
wrapper around `org-todo', e.g. `org-todo-timewarp' or
`org-retroactive-todo', which interactively prompts for a timestamp
before invoking `org-todo'?

Another possibility would be to add yet another magic prefix argument
to `org-todo', but it seems that is already heavily overloaded, so it
would have to be 'C-u C-u C-u C-u' which isn't particularly
convenient.

I can even imagine users occasionally wanting to mark stuff done in
the future, e.g. if they have an activity planned for tomorrow while
they're offline.  So maybe using the word 'retroactive' in the wrapper
function name is a bit too limiting.

Cheers,
Adam



Re: Policy proposal: Do not move existing functions/macros except in major version increments

2020-06-01 Thread Adam Porter
Hi Bastien,

On 6/1/20, Bastien  wrote:
> Hi Adam,
>
> Adam Porter  writes:
>
>> The relatively recent moving of org-get-outline-path to org-refile.el
>> has caused breakage in Org itself in several places, e.g.
>>
>> https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00260.html
>> https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00259.html
>> https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00261.html
>
> ahem, my bad.  I made this bold (and wrong) move, and I broke code out
> of org-mode.
>
> I understand your proposal, and it's always good to be reminded that
> many people depend on Org's code out there.  It is not easy to spend
> time working on Org *and* tracking all these interesting extensions.

Of course, no one could be expected to keep track of all those things.
Such is the nature of writing software that runs in a Lisp image,
where anyone can use anything, and does.

> I agree with Nicolas that we should not put more constraints on the
> shoulders of Org current developers, especially because their time is
> limited - and obviously not enough to cope with every request.

I mostly agree with you.  My request is simply that, when a change has
the potential to break third-party packages, and it's a change, such
as this one, that mostly moves code around for organizational
purposes, that it be delayed until the next major version.  My goal
for such a policy would be to reduce the frequency of such changes
that third-party package authors have to write compatibility code for.
The (if (version< org-version ...)) workarounds become confusing for
authors and users, and somewhat of a maintenance burden.

> That said, we can make it easier for third-party developers to know
> what changes will be released in the future.
>
> See the "Upcoming changes" in https://updates.orgmode.org
>
> You can subscribe to this RSS feed:
> https://updates.orgmode.org/feed/changes
>
> Or check the data directly:
> https://updates.orgmode.org/data/changes
>
> To announce the change you see, I just used this email header:
>
>   X-Woof-Change: 9092c289 9.4
>
> That is the commit number where the change happens and the version
> in which the change will be released.
>
> The list of upcoming changes is emptied when a new major released is
> done, because the changes are then advertized in this file, as usual:
> https://orgmode.org/Changes.html
>
> I think that's a tiny distributed effort for developers and a easy
> way to track changes for third-party developers.

That's a very clever way to do it!  Thanks for your work on this.  If
it's feasible, you might also consider allowing committers to put such
a header in the git commit log and parsing it out of that, which could
make it even easier.

Thanks,
Adam



Re: org-clip-link should be included in core

2020-05-24 Thread Adam Porter
On Sat, May 23, 2020 at 10:14 AM Bastien  wrote:

> So IIUC the need is to easily remove the link part of a link.
>
> I pushed a change to make this easier.  Now you can hit `C-c C-l' on
> a link, empty the link part, keep the description and RET to get only
> the description inserted as non-link text.
>
> Let me know if this seems okay for you.
>
> I'm copying Adam as he may comment on that too.

That seems like an elegant solution.  Thanks, Bastien.



Re: Policy proposal: Do not move existing functions/macros except in major version increments

2020-04-22 Thread Adam Porter
Hi Nicolas,

Nicolas Goaziou  writes:

> Hello,
>
> Adam Porter  writes:
>
>> The relatively recent moving of org-get-outline-path to org-refile.el
>> has caused breakage in Org itself in several places, e.g.
>
> [...]
>
>> Thankfully, Kyle has proposed a patch to revert that change.  I hope
>> it is merged.
>>
>> If it is not, when a new Org version is released with those changes
>
> What makes you think a new Org would be released in this situation,
> without fixing it first?

I don't know what will happen.  I don't know whether the Org maintainers
would consider the problem serious enough to avert (as you said later,
"it happens").  That's why I pointed out what the consequences would be
if the patch isn't merged, to encourage its merging.

>> I think changes like this should not be made without very careful
>> consideration of the wider implications.  These kinds of changes
>> create a not-insubstantial burden on maintainers of Org-related
>> packages to keep up with churn and maintain compatibility with
>> multiple Org versions (which are used in the wild for years--I know
>> of users still using Org 8, as well as Org 9 versions that are
>> included with older Emacs versions (e.g. Emacs 26.3 is still stuck in
>> Debian unstable, not migrating to testing, stable, or backports)).
>
> [...]
>
>> So, I propose that changes like these should not be made except in
>> major version increments, e.g. this change should have been delayed
>> until the release of Org 10.0.  It would be helpful for users and
>> package authors if they knew that changes like these would not be
>> made until the next major version increment.
>
> FWIW, I think this is too strong a requirement.
>
> This breakage is unfortunate, and I can hear the consequences it has
> on the Org ecosystem, but, hey, it happens. Note that moving part of
> Org elsewhere usually introduces less friction. This is a relatively
> exceptional situation.

Of course, I am biased here, but I feel like it's not quite as
exceptional as it ought to be.  The more Org-related packages I make and
maintain, the more version-specific workarounds I have to add due to
changed function names, signatures, etc.  These are sometimes necessary,
of course, but I think they should be made more carefully and
deliberately.

Of course, Org doesn't make any promises to third-party packages.  But
that is the issue, isn't it?  I'm saying that I think it should start
taking this issue a little more seriously.  :)

> Master is an unstable branch, relatively open to experimentation.
> Moreover, that experimentation happens before deciding if the next
> release should be 10.0 or 9.4, so it wouldn't help users or package
> authors.

That is a matter of policy, which is what I'm proposing.  When such a
change is desired (symbol name, function signature, etc), it should be
targeted at the next major version increment.  If the project as a whole
is not ready to make that increment, that change should be delayed until
then--it can be developed in a branch and merged when preparing the
major release.  These kinds of changes could even be documented in
advance, e.g. in a ROADMAP or PLANS file, or whatever you want to call
it, which would be more explicit and referenceable than merely a mailing
list post.

> It doesn't mean we cannot do better here. For example, I think we
> could improve the way Org loads its libraries. Ideally, external
> libraries should only (require 'org), and optionally, (require 'ox-*)
> or (require 'ol-*). Thus, changes like the one discussed here would be
> implementation details. For example, "ox-hugo.el" requires directly
> "ob-core.el", and now "org-refile.el", which is, IMO, a path to
> troubles. It should only require "org.el".
>
> The current situation is tricky though: "org.el" requires some
> libraries (e.g., "org-key.el", "org-table.el", ...), and some
> libraries require "org.el" (e.g., "org-capture.el", "org-element.el",
> ...). I expect "org.el" to be the entry point for the Org package, so
> loading should happen in one-way only.
>
> This would not solve everything, but it would certainly make things
> smoother for external libraries.
>
> WDYT?

That is a good idea, and one that needs addressing.  I'd be glad to give
some feedback on it, but in a separate thread, please, because it seems
like a different matter from the issue I'm raising and the proposal I'm
making.

Thanks,
Adam




Re: [ANN] org-ql 0.4 released

2020-04-22 Thread Adam Porter
David R  writes:

> On Saturday, January 25, 2020, Adam Porter  wrote:
>
>> I care about stability, not MELPA Stable.  It's your choice to use MELPA
>> Stable, and you're free to upgrade or downgrade individual packages to
>> work around such occasional, temporary breakage caused by it--the pieces
>> are yours to keep.  I'm sorry for any inconvenience, but your config is
>> up to you.
>
> It seems to me that this last statement ("Your config is up to you"),
> or perhaps the point of view that produces it, is not self-evident
> when applied to package versions. I think that in some way it's near
> the heart of the controversy.
>
> Maybe for me personally, my config being up to me (regarding package
> versions) is a disadvantage. I gratefully make use of a number of
> packages that I don't fully understand, and if I was required to study
> all of them until I was confident that I *did* fully understand them
> before installing, I'd just give up using Emacs at all.

That is not what I am suggesting.

I suggest that you:

1.  Keep your Emacs config backed up, preferably with version control,
including all installed packges.

2.  Upgrade packages deliberately, not "upgrade all upgradable
packages."

3.  When you discover a problem caused by an upgrade, roll-back to a
known-good configuration until you have time to debug the problem.

This is what I recommend to all Emacs users.  It does not require
understanding any packages' source code.

Elisp has no inter-package API.  It's just a Lisp machine.  Elisp
packages are just symbols that you load into your image.  There is no
actual separation between packages' symbols.  There are no versioned
APIs, no synchronized transitions.

Each user's configuation, image, set of installed packages, etc. is that
user's responsibility.  In that sense, it's no different from a computer
system as a whole: you choose what software to install on it.  If you
like or need a certain version of certain software, it's up to you to
ensure that you have a copy of it available.  If you upgrade some
software and it doesn't work anymore with some other software version,
it's up to you to deal with it.

One of Emacs's chief strengths is user empowerment.  That doesn't mean
that users need to know how everything works--not even the core Emacs
developers do.  It means that you should know enough to maintain the
operability of the system, like you generally do for the rest of your
computer system.

The Emacs package "ecosystem" is not a "vendored" system.  It's not like
Debian, with thousands of relatively curated packages maintained as a
middleman, expected to work together in a stable release.  In Emacsland,
Each package (outside of Emacs and ELPA, and somewhat within ELPA as
well) is developed independently.

Nor should Emacs be treated like other software systems that are
live-updated whenever the developers hit the "push" button, with users
expecting the latest everything to work together all the time because
one party (ostensibly) takes responsibility for ensuring that.

Emacs gives the user the power.  And with great power...well, you know.

Having said all that, the problems with MELPA Stable are, in a sense,
artificial, and they're orthogonal to these general issues.  I can only
recommend, again, to not use it.  If you're lucky, it will work fine.
When it doesn't, the solution will involve not using it.  So you might
as well just skip it.  If you want less-frequent package upgrades, just
don't upgrade your packages so frequently.  Or use something like Quelpa
or Straight or Borg, where you can easily install the package versions
you want.




Policy proposal: Do not move existing functions/macros except in major version increments

2020-04-16 Thread Adam Porter
The relatively recent moving of org-get-outline-path to org-refile.el
has caused breakage in Org itself in several places, e.g.

https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00260.html
https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00259.html
https://lists.gnu.org/archive/html/emacs-orgmode/2020-04/msg00261.html

Thankfully, Kyle has proposed a patch to revert that change.  I hope it
is merged.

If it is not, when a new Org version is released with those changes
(actually, sooner, because some users run the master branch), it will
cause further breakage in out-of-tree packages and code in user
configurations.

I think changes like this should not be made without very careful
consideration of the wider implications.  These kinds of changes create
a not-insubstantial burden on maintainers of Org-related packages to
keep up with churn and maintain compatibility with multiple Org versions
(which are used in the wild for years--I know of users still using Org
8, as well as Org 9 versions that are included with older Emacs versions
(e.g. Emacs 26.3 is still stuck in Debian unstable, not migrating to
testing, stable, or backports)).

For my own packsges, I would expect to get multiple bug reports for
several of my packages, which means that for each one, I then have to
deal with the report, make a fix, test it, log it, push it, close the
bug report...and for all that, nothing is gained.  It adds up, and it's
frustrating and demoralizing.

Of course, I am not opposed, in principle, to refactoring and
reorganization of this sort.  Org is a huge project, and it certainly
could benefit from these kinds of changes, in general.

So, I propose that changes like these should not be made except in major
version increments, e.g. this change should have been delayed until the
release of Org 10.0.  It would be helpful for users and package authors
if they knew that changes like these would not be made until the next
major version increment.

If this is agreeable to the Org maintainers, I'd ask that it be
documented in the project and announced in the NEWS file.

Thanks,
Adam




Re: I'm slowly coming back

2020-04-13 Thread Adam Porter
Hi Bastien,

I've been keeping an eye out for you!  :)  Glad to hear you're well, and
I'm looking forward to your return.

Adam




Re: Assistant to remove unused IDs of org-id

2020-04-13 Thread Adam Porter
Marc-Oliver Ihm  writes:

> as I use the excellent package org-id in a somewhat non-standard way,
> I tend to produce IDs, that are not referenced from anywhere. Org-id
> handles this great and does not suffer in performance, but eventually
> I want to remove those unreferenced IDs.  Therefore I have written a
> small interactive assistant:
>
> https://github.com/marcIhm/org-working-set/blob/master/org-id-cleanup.el
>
> to help with removing those IDs.  The assistant (interactive function:
> org-id-cleanup) is quite detailed with its instructions and checks, so
> that the risk of doing harm ist reduced to a minimum, although not to
> zero (therefore the first step is to ask for a backup).
>
> In any case I wonder, if this functionality (removing unreferenced
> IDs) could be helpful for anyone else.
>
> So please feel free to have a look.  Finally I would be grateful for
> any comment whatsoever (e.g. regarding the name of org-id-cleanup.el).

Hi Marc,

Thanks, this looks useful.  I posted some feedback as an issue on the
repository.

Adam




Re: Org-babel-lilypond always renders full pages

2020-04-01 Thread adam
On Wed, 2020-04-01 at 11:02 +0200, Oliver Heck wrote:
> > Off-topic:  Oliver is exporting/engraving to a fixed-resolution png. An 
> > alternative
> > is to export scalable vector graphics of the score to PDF.
> 
> PDF does scale better, but it does not help because I need the original 
> size embedded.
> 
> Logically it works fine when full staves are rendered (at least they all 
> have an identical scaling factor then), but I often have very small 
> snippets like single bars or fretboard diagrams.
> 
> Oliver
> 

Understood, Oliver.  And I'm sorry for crashing in. 


FYI,  I have had the most success in using the pdf-example.org  of this page, 
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html 

as that exports EPS to PDF, not what you're after. 

I've cut  pdf-example.org down and include an import from  midi2ly  as shown 
here. 

This helps, as the imported ly file has its \layout { .. } block which 
is informative and allows further editing along with the imported score.  


* Importing from MIDI 
Lorem ipsum dolor sit amet, consectetur ... etc 

#+LaTeX: \linebreak
#+ATTR_LaTeX: width=17cm
#+begin_src lilypond :file patterns-1.eps :noweb yes

\include "patterns1-midi.ly"

#+end_src

#+RESULTS:
[[file:patterns-1.eps]]











Re: Org-babel-lilypond always renders full pages

2020-03-31 Thread adam
On Tue, 2020-03-31 at 10:48 -0300, Jonathan Gregory wrote:
> Hi
> 
> On 30 Mar 2020, stardiviner  wrote:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> > 
> > 
> > stardiviner  writes:
> > 
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA256
> > > 
> > > 
> > > You might want to try this:
> > > 
> > > #+begin_src emacs-lisp
> > > (add-to-list 'org-babel-default-header-args:lilypond
> > >  '((:prologue . "\paper{
> > >   indent=0\mm
> > >   line-width=120\mm
> > >   oddFooterMarkup=##f
> > >   oddHeaderMarkup=##f
> > >   bookTitleMarkup = ##f
> > >   scoreTitleMarkup = ##f
> > > }")))
> > > #+end_src
> > > 
> > 
> > I found this custom setting lilypond header arguments will not work. 
> > Because this code
> > function:
> > 
> > #+begin_src emacs-lisp
> > (defun org-babel-lilypond-get-header-args (mode)
> >   "Default arguments to use when evaluating a lilypond source block.
> > These depend upon whether we are in Arrange mode i.e. MODE is t."
> >   (cond (mode
> >  '((:tangle . "yes")
> >(:noweb . "yes")
> >(:results . "silent")
> >(:cache . "yes")
> >(:comments . "yes")))
> > (t
> >  '((:results . "file")
> >(:exports . "results")
> > 
> > (defun org-babel-lilypond-set-header-args (mode)
> >   "Set org-babel-default-header-args:lilypond
> > dependent on ORG-BABEL-LILYPOND-ARRANGE-MODE."
> >   (setq org-babel-default-header-args:lilypond
> > (org-babel-lilypond-get-header-args mode)))
> > #+end_src
> > 
> > It always reset and return one result of two conditions.
> > 
> > I think this is a bug.
> 
> So are all org-babel-default-header-args:LANG custom variables? In the
> ob-lilypond.el library the headers are hard-coded.
> 
> [...]
> 
> --
> Jonathan
> 


Hi all.  This is very interesting. 


I quickly tried setting the   org-babel-default-header-args:LANG   using 
exactly 
the src emacs-lisp  example block above.  

However that variable remained nil before and after org export lilypond to PDF. 
Am sure I must have done something wrong. 

Thank you for drawing my attention to that variable, as it seems the right 
place 
for  lilypond  headers and options too. 


Off-topic:  Oliver is exporting/engraving to a fixed-resolution png. An 
alternative 
is to export scalable vector graphics of the score to PDF. 

   
 
   








Re: virtual org-mode meetup tomorrow 11am EST

2020-03-29 Thread Adam Porter
Ihor Radchenko  writes:

> FYI:
> I have recently stumbled upon a FOSS service for video conferencing:
> https://meet.jit.si/ (recommended in Tor blog
> https://blog.torproject.org/remote-work-personal-safety) 
>
> Might be another option for future meetings.

Yes, that's what was used for EmacsConf 2019.  It seemed to work well
enough.  See the archived videos.




Re: Automatic formatting of the table as you type

2020-03-29 Thread Adam Porter
ndame  writes:

> As for org-at-table-p being slow storing the start and end position of
> the table could be a solution, so if point is between them then there
> is no need to check org-at-table-p again.
>
> org-table-align seemed fast enough for me when I tried the posted
> code, but if it's slower for large tables then the code could measure
> the time it takes to perform the alignment for the current table and
> if it's above a certain threshold then it could introduce a bit of
> idle delay for the update, so it doesn't hold back the user from
> typing, and if the alignment is fast then it could perform the update
> without delay.
>
> Anyway, I think if implemented properly then this feature could be a
> worthy addition to org, even as default if it works well, because it's
> a much better user experience and a much better first impression for
> new users, instead of the current default fragile table which falls
> apart during typing and fixed only when TAB is pressed.

I suggest being very careful with this.  While it's a very nice feature,
it's bound to be slow with large tables.  And it is very frustrating for
users when typing becomes laggy.  Most users who encounter it would
probably not know if there's a way to fix the problem, e.g. by disabling
a feature, because they probably wouldn't even know what to look for.
Most would probably think it a bug, and it could harm Org's and Emacs's
reputation, making people think they're inherently slow or laggy when
typing.

Pressing TAB (or any other key that moves to the next field) to realign
a table is not a significant burden.  A feature like this should
probably remain an add-on package, or at least disabled by default.




Re: org-pop-mode

2020-03-18 Thread Adam Porter
"Mark E. Shoulson"  writes:

> Heh; fair enough.  The filename originally was "org-level-end.el", I
> think; I started using the catchier "org-pop" because... well, it was
> catchier.  It made sense in my mind, in the "push"/"pop" sense used
> with stacks in programming, that you "push" to a deeper level and this
> library would allow you to "pop" back up to a higher one.  I'll see if
> I can think of something better, thanks.

Well, org-heading-push-pop wouldn't be a /great/ name, but the push/pop
paradigm is understandable, so you might consider that.  :)

>
>> 2.  In the code, I saw you comment about cl-flet, and I see you using
>> fset and unwind-protect in the org-pop-with-continuations macro.
>> Instead, use cl-letf with symbol-function, like:
>>
>>(cl-letf* (((symbol-function 'foo)
>>#'my-foo)
>>   ((symbol-function 'bar)
>>(lambda ()
>>  ...)))
>>  BODY)
>>
>> See also Nic Ferrier's package, noflet.
>
> I'll take a look, thanks.  It's questionable whether I really should
> even be messing about with that macro anyway.  I musnt have removed the
> comments, but I had a whole thing there about how I had been trying
> with cl-letf and/or cl-flet and it didn't work. Thing is, cl-flet,
> according to the docs, (info:cl#Function Bindings) is strictly
> *lexical* binding, which is not going to cut it.  cl-letf might be
> different; the docs are different about it, but I am pretty sure I
> tried it and it didn't work, or didn't work "enough of the time."  But
> maybe I had it wrong, and maybe noflet will succeed.

The issue is what the macros expand to.  cl-letf rebinds the function
symbols, just like fset, so it affects all code that runs in Emacs until
the function symbols are set again.  cl-flet expands into lambdas bound
to variables and replaces calls to them with funcall, so it only affects
calls in the macro's body.  Use pp-macroexpand-last-sexp to see the
expansions.

BTW, in the body of your email, the text you write has these two
characters between sentences: "  ".  The second is a plain space, but
the first is a Unicode non-breaking space, or "C-x 8 RET a0".  I noticed
because it's displayed in Emacs as an underline character next to the
plain space.




Re: org-pop-mode

2020-03-18 Thread Adam Porter
"Mark E. Shoulson"  writes:

> This is something I've wanted for years in org-mode, but which in some
> ways could actually be _offensive_ to its ideals.  If you're an
> outline purist, look away.
>
> ...
>
> So, I present a pre-alpha version,
> https://gist.github.com/clsn/09ac4b098b6ad7366bb5e0bc2d5f of
> org-pop-mode.  To "pop" back up, create a headline at the level you're
> popping back to, and give it a tag of "contd", and the headline text
> should not be something important.  Instructions and explanations are
> in the comments of the file (the part about installing from MELPA is a
> lie, though).
>
> Any feedback?

Hi Mark,

Indeed, this is something that is frequently asked about.  I probably
wouldn't use it myself, but it looks like you've done a good job on it.
Here is some feedback:

1.  I'd suggest a more descriptive name, especially if you plan to
publish it to MELPA.  org-pop doesn't seem to convey anything about what
it does.  :)

2.  In the code, I saw you comment about cl-flet, and I see you using
fset and unwind-protect in the org-pop-with-continuations macro.
Instead, use cl-letf with symbol-function, like:

  (cl-letf* (((symbol-function 'foo)
  #'my-foo)
 ((symbol-function 'bar)
  (lambda ()
...)))
BODY)

See also Nic Ferrier's package, noflet.




Re: ox.html causes w3c xhtml validation

2020-03-15 Thread Adam Porter
Colin Baxter  writes:

> In my opinion, if it can't be fixed then the changes should be
> removed. Surely, we cannot have an org-mode that knowingly
> exports/publishes something that causes a validation error!

Looking at the error message, the fix might be very simple:

  The most common cause of this error is unencoded ampersands in URLs as
  described by the WDG in "Ampersands in URLs".




Re: virtual org-mode meetup tomorrow 11am EST

2020-03-15 Thread Adam Porter
Thanks to John for hosting, and to all who "attended" virtually.  It was
great fun.  Looking forward to doing it again.




Re: [PATCH] Add NO-STATS switch to org-get-heading

2020-03-13 Thread Adam Porter
Please don't add more arguments to org-get-heading.  It used to have 2,
then it had 4, and now you want to add a 5th.  Every time the function's
signature changes, it breaks code in third-party packages and user code
in random places, which requires the addition of messy compatibility
code and intermediate functions that do nothing but wrap org-get-heading
with a certain number of arguments.

It would be much preferable to make a new function that uses keyword
arguments so the addition of more arguments won't affect existing code.
Maybe it could be called org-entry-heading.




Re: Debugging at least 2 regressions in org-mode master breaking ox-hugo

2020-02-27 Thread Adam Porter
Kaushal Modi  writes:

> Failure 1: org-get-outline-path has moved, and not mentioned in ORG-NEWS
>
> Compiling ox-hugo.el now gives:
>
> ox-hugo.el:4284:1: Warning: the function ‘org-get-outline-path’ is not known 
> to be defined.
>
> I see that defun has now moved to org-refile.el. I see that
> org-get-outline-path has nothing to do specific to refiling. Can that
> be moved back to org.el, or may be a separate library? Otherwise,
> ox-hugo.el will have to load org-refile.el too (yes, I don't use
> org-refile (yet), and that's how I discovered this :))

Yes, please move that function back.  This is going to cause breakage in
a variety of packages that use that function but do not load
org-refile.  I can hear the bug reports rumbling already...  ;)




Re: Regarding collapsing blank lines between headlines

2020-02-19 Thread Adam Porter
Hi Russell,

This is not exactly what you asked for, but here's some code that
ensures blank lines exist between headings and entry content.  You could
modify it to remove excess lines without too much trouble.

https://github.com/alphapapa/unpackaged.el#ensure-blank-lines-between-headings-and-before-contents




Re: Survey: changing a few default settings for Org 9.4

2020-02-19 Thread Adam Porter
Marco Wahl  writes:

 - org-loop-over-headlines-in-active-region => t
>>>
>>> I vote for => 'start-level.  Loop over headlines with same level as the
>>> first.
>>
>> Yes, good suggestion.
>
> Let's see what others say.

I can see how that could be useful, but I feel like it would be less
intuitive than looping over all headings in the region.  I would be
confused by that behavior if I weren't aware of this discussion and the
option's settings.  So I would vote for t over 'start-level.

My two cents.  :)




Re: Survey: changing a few default settings for Org 9.4

2020-02-19 Thread Adam Porter
I generally approve of all of these changes.  However, hiding emphasis
and macro markers can make editing text at the boundaries of emphasized
text non-intuitive, which I can imagine might frustrate some new users,
so that should probably be carefully considered.  The other changes seem
like obvious improvements to me.  :)  Thanks for your work on this,
Bastien!




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

2020-02-19 Thread Adam Porter
Hi Bastien,

Bastien  writes:

> Hi Adam,
>
> Adam Porter  writes:
>
>> https://alphapapa.github.io/org-almanac/
>
> this is a very nice list of resources!
>
> Do you think we can advertize it somewhere on Worg?
>
> If yes but are unsure *where*, just go ahead with whatever location
> seems fine, we can always rearrange Worg's contents later on.

Yes, I'd be glad for it to be listed on Worg.  Feel free to add it if
you like, or I might add it myself after I add a bit more content.

I was thinking about working on Worg rather than making yet another
resource, but:

1.  I saw you mention that you're planning to reorganize Worg's content
soon, and I wouldn't want to interfere with that.

2.  I sometimes feel hesitant to put a lot of effort into curating and
organizing content on Worg because, like all wikis, that work can easily
be invalidated if others come along later and add content in random
places.

One of my goals for this "org-almanac" is to catalog content in a
somewhat canonical way, to avoid the "wiki effect."  For this project,
I'd rather have less content that's organized more clearly, than have
lots of content scattered about.  Of course, I don't presume to say that
the way I've done it is the best way, and I'm experimenting as I go.

Anyway, do you have any more thoughts about these issues?

Thanks,
Adam




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

2020-02-14 Thread Adam Porter
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. 
>
> 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"
>
> Stig

Hi Stig,

Thanks for sharing that.  I think this is a fairly common question among
Org users, yet not always easy to find the answer to, so I've added your
example here along with a couple of other solutions:

https://alphapapa.github.io/org-almanac/#Exclude%20and%20include%20tags%20in%20custom%20Agenda%20commands




Re: [PATCH] ox.el: Fix extra character deleted in org-export--update-included-link

2020-02-13 Thread Adam Porter
Dear Nicolas and Bastien,

I feel like a child whose parents are fighting.  :)  If I may speak for
other Org users: you're invaluable to us, and we look up to you.  Please
don't let the deficiencies inherent in online, textual communication
cause deterioration in your fellowship.

With gratitude for all your contributions,
Adam




Re: Provide org-insert-subitem

2020-02-13 Thread Adam Porter
Bastien  writes:

> First of all, don't be afraid, I don't have a grand plan for "cleaning
> up" things.

Don't worry, I trust you.  :)  Org wouldn't be what it is today without
your work, and I'm grateful for how much time you've been putting into
improving Org lately.

>> I'm not sure what you mean about functions mentioned as usable by the
>> user.  org-insert-subheading is an interactive command, so it's
>> explicitly usable by the user.
>
> Yes, org-insert-subheading is interactive and usable and in Org's core
> but how can a user *discover* this command?
>
> There is no keybinding for it and no mention in the manual.  Even as a
> function, it is not even used in Org codebase.
>
> The ways I can see for a user to discover this command is by trying to
> complete M-x org-insert TAB or by reading Org's code (or other code in
> the wild using it.)

I guess what happened here is that I found that command years ago,
probably from either reading someone else's config online or, as you
say, using completion (I discover so many things using Helm
completion--I'm constantly using "C-h f org-" when working on
Org-related code).  Then I bound it to S-RET in my config, and I've been
using it ever since.  To me it feels like just as much a part of Org as
any other Org command.

> So to me it's a "utility" command: something that Org does not depend
> on, something that provides a useful feature, but not useful enough to
> have a keybinding in Org's core or to be used as a function in Org's
> core.

What if we document it in the manual?  For example, in section 2.5,
"Structure editing", we have:

`M-' (`org-insert-heading')
 Insert a new heading/item with the same level as the one at point.

`C-' (`org-insert-heading-respect-content')
 Insert a new heading at the end of the current subtree.  

`M-S-' (`org-insert-todo-heading')
 Insert new TODO entry with same level as current heading.  See
 also the variable `org-treat-insert-todo-heading-as-state-change'.  

`C-S-' (`org-insert-todo-heading-respect-content')
 Insert new TODO entry with same level as current heading.  Like
 `C-', the new headline will be inserted after the current
 subtree.  

What if we add:

`S-' (`org-insert-subheading')
 Insert a new subheading and demote it.
 Works for outline headings and for plain lists alike.

Note that I also propose binding it to S-.  It seems that, by
default, that key is currently bound in Org buffers to
org-table-copy-down:

Copy the value of the current field one row below.

That's surely a useful function, but I feel like it probably isn't
widely used enough to deserve to be bound to S- in all contexts.
Of course, frequent users of this command, feel free to correct me, lest
I be a hypocrite.  ;)

If that seems agreeable, then I'd also propose renaming the command
(preserving its old name in an alias, of course) to something which
would not imply that it only works in outlines, perhaps
org-insert-subitem or org-insert-demoted.

In the longer term , perhaps we could make a new, contextual command
that would call one command in tables and another command in non-table
contexts.  If there were a clever way we could make similar, roughly
corresponding actions in both tables and tree structures use the same
bindings contextually, that might be useful.  I think it would be
reasonable, because if point is in a table, the user probably won't want
to insert a new outline heading in the middle of it.

What do you think?  Thanks.




Re: Provide org-insert-subitem

2020-02-12 Thread Adam Porter
Hi Bastien,

Bastien  writes:

> I still find it strange to keep functions that are used nowhere in the
> Org's core--except of course for functions that explicitely mention as
> usable by the user (e.g. `org-clock-persistence-insinuate'.)
>
> I'd rather have these functions stored in a org-utils.el library for
> those who care.

I'm not sure what you mean about functions mentioned as usable by the
user.  org-insert-subheading is an interactive command, so it's
explicitly usable by the user.  And it's in org.el, so it's in Org's
"core", right?  I guess we're thinking in different terms.

Inserting a subheading or subitem is a very common operation in an
outlining and list-making tool, so it would seem like a significant
regression to remove it.

I'm not opposed to reorganizing the code, of course, as long as it
remains loaded as a command when org-mode is activated.




[ANN/RFC] org-ql-view-dispatch command

2020-02-10 Thread Adam Porter
Hi friends,

I've pushed a new feature to org-ql's master branch: a Magit-like view
dispatcher using Jonas Bernoulli's transient.el library.  It makes for
quick and easy modification of org-ql-view queries, allowing you to
build them interactively rather than requiring you to write Lisp code or
use the Customization system.  Here's a screencast of it:

https://github.com/alphapapa/org-ql/raw/master/images/org-ql-view-dispatch.gif

It seems to work well, but I'd appreciate any feedback.

Thanks,
Adam




Re: How to intersperse commands with their output in RESULTS block?

2020-02-07 Thread Adam Porter
Diego Zamboni  writes:

> I came up with the following block, which cleans up all the cruft from
> the output of the =script= command and produces a nicely formatted
> session transcript:
>
> #+NAME: cleanup
> #+BEGIN_SRC emacs-lisp :var data="" :results value :exports none
>   (replace-regexp-in-string
>"\\$ exit\\(.\\|\n\\)*$" ""
>(replace-regexp-in-string
> "^bash-.*\\$" "$"
> (replace-regexp-in-string
>  "\\(\\(.\\|\n\\)*?\\)\\$\\(.\\|\n\\)*\\'" ""
>  (replace-regexp-in-string "
> " "" data) nil nil 1)))
> #+END_SRC
>
> (I am not happy with the regexp nesting and repetition above, I am not
> an expert yet in emacs-lisp regex facilities. Suggestions appreciated
> for how to simplify it).

Hi Diego,

A few suggestions:

1.  You can use `rx' to define regexps in a Lispy way, and the ELPA
package `xr' converts existing regexp strings to the rx format, which
can help in learning rx syntax.  For example:

  (xr "^bash-.*\\$" 'brief) ;;=> (seq bol "bash-" (0+ nonl) "$")

So you can use that regexp like:

  (replace-regexp-in-string (rx bol "bash-" (0+ nonl) "$") ...)

This nasty one is much easier with rx:

  (xr "\\(\\(.\\|\n\\)*?\\)\\$\\(.\\|\n\\)*\\'" 'brief)
  ;;=>
  ;; (seq (group (*? (group anything)))
  ;;  "$" (0+ (group anything)) eos)

2.  To avoid the nested calls, you can use a loop, like:

  (cl-loop for (match replace) in
   (list (list (rx foo bar) "replacement"))
   do (setf string
(replace-regexp-in-string match replace
  string)))




Re: org-adapt-indentation default should be nil [legibility 3/6]

2020-02-05 Thread Adam Porter
Texas Cyberthal  writes:

>> the default settings do not put blank lines between headings and
>> their entry text,
>
> I don't know what this means. Plain Emacs behaves the same way
> Spacemacs does in this regard. Insertion of a blank line after a
> heading is voluntary but standrd.

I don't know what you mean, either, but you keep mentioning Spacemacs,
which isn't very relevant.

>> without any indentation, headings and entry text on varying levels
>> tends to blend together, making for very poor readability.
>
> If the goal is to read the body text of headings, then deeply
> indenting it is contrary to the goal. If the goal is to see the depth
> of headings, then the bodies should be folded. If folded mode doesn't
> convey sufficient information, the solution is to rewrite the heading
> titles to better summarize the body text.

It is not for you to decide what others should do.  Your preferences are
not mine.  It sounds like you should develop your own "Texas Cyberthal
Emacs starter kit" that has all the settings you think are best.

>> No one is "good at" Emacs and Org when they first come to it.
>
> UI difficulty is exponential, not linear.

Come on, we all know that the Emacs learning curve is a spiral.

> The more initially difficult the Emacs UI is acknowledged to be, the
> more important it is to reduce that difficulty with noob-friendly
> defaults, so that they can eventually reach the point of elitist
> unconcern for noobs.

The issue here is not whether Emacs can generally be improved, but
whether your specific proposals are good ideas.

It's unfriendly of you--and incorrect--to imply that we are elitists
without concern for new users.  Much effort is put into improving
documentation, answering questions, writing explanatory articles, giving
demonstrations, etc.  Some of us even publish code to help others
improve their configs, e.g. https://github.com/alphapapa/alpha-org.  I
suggest that you give those avenues a try, rather than insisting that
your preferences are best for others.

> The problem with aiming software at noobs is ruining the expert
> experience.

That is one problem with software that overemphasizes the experience of
new users.  Another, perhaps more serious, problem is that it inhibits
the development of such expertise.  I feel like some of ESR's writings
are relevant here.

> Changing defaults doesn't ruin expert experience because experts have
> configuration management.

A VCS does not obviate the need to compensate for changes in default
behavior.

> Noob friendly defaults increases the likelihood there is a long term
> for them.  Emacs' biggest barrier to adoption is acclimatization.

You're not quite wrong, but you're missing the point about long-term
users.  What makes software attractive in the long-term is not what
makes it appeal to new users.  Emacs is not called "the editor of a
lifetime" for nothing--nor is notepad.exe called that, even though it is
very easy for new users to use.  Emacs is attractive in the long-term
because of its power, flexibility, and potential for mastery.  There is
a balance to be struck between appealing to new users and empowering the
development of expertise; to an extent, the two goals do conflict.

> I just read a GTD thread in which they all agreed Org was too hard to
> be worth learning, including the guy advocating it:
>
> https://forum.gettingthingsdone.com/threads/emacs-org-mode-is-the-perfect-tool-for-gtd.15028/page-2
>
> To be clear, this is the biggest GTD forum, which Org is the best
> implementation of, and it seems most of them are using digital GTD
> tools.

So what?  Emacs and Org do not need to adapt themselves to users who do
not like them.  They are successful because of what they are.

You seem very concerned about new users, thinking that, unless we make
Emacs/Org very easy for new users to understand, there will be no new
users.  This is obviously not the case.  Emacs is one of the oldest
pieces of software still widely used.  It and Org are gaining new users
every day; the community is more vibrant than ever.  Probably more
people use Emacs and Org today than ever before.

Consider an analogy: Years ago, Mozilla Firefox was the fastest, most
powerful, most popular browser that wasn't imposed on its users.  It was
the obvious victor in the "browser wars," having led the way in
unseating IE and freeing the Web from Microsoft's hegemony.  Then Google
Chrome arose as a challenger, with certain inherent advantages due to
Google's position.  Mozilla then chose to stop leading and start
following.  Every new Firefox release became more like Chrome, with
Mozilla thinking that it could win back users.  But why would a user who
was happy with Chrome want to switch to a poor imitation of it?  Mozilla
thought it could succeed by abandoning what had made it successful--it
thought Firefox would be more popular if it stopped being Firefox.  The
result was continued decline in Firefox's market share and, eventually,
Mozilla's 

Re: org-startup-truncated default should be nil [legibility 2/6]

2020-02-05 Thread Adam Porter
Texas Cyberthal  writes:

>> visual-line-mode and toggle-truncate-lines are basic Emacs commands
>> that all users should learn early.
>
> Visual lines, logical lines etc is a complicated mess that Spacemacs
> avoids entirely. I recall fiddling with it and never being satisfied,
> until adopting Spacemacs solved it. Now I know even less about it than
> I did then, because there's no need to know. A brief investigation
> shows Spacemacs sets (line-move-visual t) in prosey text modes, so
> that C-n next-line operates on visual lines. However commands such as
> C-e operate on logical lines: mwim-end-of-line-or-code. This is a sane
> default that permits fluid navigation of paragraphs, which is all a
> noob wants to do.
>
> Similarly, I almost never use truncate-lines, to the point that I had
> to websearch to recall what it was called within the last week.

If I understand correctly, you're arguing that defaults should be
changed because you don't understand how Emacs works, and since you use
Spacemacs, you don't even care how it works.

May I suggest that you propose your changes on the Spacemacs repo.




Re: Defaults for noobs, dotfiles for vets [legibility 1/6]

2020-02-05 Thread Adam Porter
Texas Cyberthal  writes:

> Making a vet change a default if he decides he doesn't like a change
> upon upgrading won't drive him away, but Emacs' unfriendly defaults
> are always driving away noobs. Therefore Org's defaults should be
> noob-friendly, not vet-friendly.

There is certainly room to improve some Emacs defaults; there are active
threads on emacs-devel about it now.

However, the question of to what degree Emacs should target certain
types of users is a wider one, and answering it one way or the other
doesn't necessarily support your proposed changes.

> Probably vets should use legible settings as well. I became accustomed
> to less-legible Org settings, and thought they were superior. But when
> I cleaned up my Spacemacs config, I incidentally restored some default
> legibility tweaks I'd disabled. After a brief exposure, I realized the
> tweaks were superior, and that my preferences had been wrong. Changing
> the defaults can overcome vet inertia and improve their UI.

It's neither the spirit nor practice of Emacs to tell users what
settings they should use.  Emacs exists to empower users to meet their
needs according to their preferences.

It is not for you, nor us, to decide whether certain users are suffering
from "inertia" which we ought to overcome on their behalf for the sake
of improving their UI.  That is for them to decide, not us.  This is
Emacs, not Apple, Inc.

>> Terminals can display colors, underlines, italics, and bold text
>
> Proposed legibility changes don't affect those font aspects.

I was responding to this claim of yours:

>>> Concerns about terminal impact appear to be moot, since terminal
>>> ignores most font settings.

So your claim has been clarified from "terminals ignore most font
settings" to "my proposed changes don't affect the font aspects that
terminals display."

Please quote enough of the message you're replying to so that the
conversation can be easily followed (by me, if no one else).





Re: org-mode functional programming library

2020-02-03 Thread Adam Porter
Nicolas Goaziou  writes:

> Note that, at some point, Org will support "seq.el", i.e., when we
> drop support for Emacs 24.

Just a small FYI about seq.el, for those who may not be aware: while
it's a very useful library, it can be quite slow since it uses generics.
For example, here are some benchmarks comparing seq-intersection with
other functions that intersect lists:

https://gist.github.com/alphapapa/36b117c178dec677258f372c3a01d8b5

Note the last benchmark listed, which shows that cl-intersection is
about 2x as fast as seq-intersection.  As well, dash.el's -intersection
is about 17x faster than seq-intersection.

So while seq.el will undoubtedly be useful in Org, it should be used
carefully with regard to performance.  Type-specific functions will
generally be much faster.  And as long as dash.el can't be used in Org
proper, a custom implementation may be called for at times.




Re: Prose with markup needs more line spacing [legibility 5/6]

2020-02-03 Thread Adam Porter
Texas Cyberthal  writes:

> Code requires less line spacing. It has more whitespace, fewer capital
> letters, and no markup such as underlining. Code is read differently
> than prose; it requires less sequential scanning.

Code certainly can have markup like underlining.  For example,
flymake/flycheck highlighting, highlight-function-calls-mode, Semantic,
etc.

> Prose has big blocks of text with taller capital letters that must be
> scanned sequentially. The tall bits bump into lines above and below.
> Org prose adds markup. Underlining and all-caps tags are common. This
> requires a bit more line spacing for optimal legibility:
>
> #+begin_src elisp
> ;; prose with markup needs more line spacing
> (defun leo-space-lines ()
>   (setq line-spacing 0.175))
> (add-hook 'org-mode-hook 'leo-space-lines)
> #+end_src

We should definitely not be messing with line spacing in default
settings.  Line spacing is a very personal preference, and it varies
widely by other configuration, such as font.

Please, feel free to make your own prose-specific Org theme or minor
mode, or use or improve one of the several that already exist.  Org
defaults need not be changed to meet your preferences.




Re: Fixed vs variable pitch font [legibility 4/6]

2020-02-03 Thread Adam Porter
Texas Cyberthal  writes:

> Readable prose requires variable-pitch font. Readable code requires
> fixed-pitch font. Org should make it easy to configure the two
> separately.
>
> mixed-pitch-mode mostly solves this problem, but only advanced users
> know about it.
> https://gitlab.com/jabranham/mixed-pitch

I also prefer proportional fonts for prose in Org buffers, and I
configured my face settings accordingly a long time ago.

However, it is not necessarily so that proportional fonts are required
for prose.  Great works have been written on typewriters for many
years.  As well, Emacs/Org are not necessarily aimed at prose writing
more than other uses, and changing the default would probably be
off-putting to many existing users, so the default probably should not
be changed.

Having said that, if Org could have a simple org-mixed-pitch-mode, or
something like that, that could be very helpful, since it could make
such configuration much easier.  Maybe one could be written to use
face-remapping, which shouldn't take much code.




Re: org-adapt-indentation default should be nil [legibility 3/6]

2020-02-03 Thread Adam Porter
Texas Cyberthal  writes:

> #+begin_src elisp
> (org-adapt-indentation nil)
> #+end_src
>
> Adaptive indentation makes sense when using Org as a plain-text
> database. It does not make sense when using Org for longform prose.
>
> In the former case, outline depth is important to reflect properties
> such as inheritance. The code elements are primary and the prose
> secondary.
>
> In the latter case, the primary payload is the prose. Gratuitously
> indenting it wastes screen space and requires the user to make layout
> adjustments for legibility. The extra information value of indentation
> reflecting outline depth is negligible; the heading already conveys
> it.
>
> Beginners are bad at making adjustments to keep heavily-indented prose
> legible. Thus the default should be nil.

I think you have a better case for changing this setting.  However, I
think there is another consideration: the default settings do not put
blank lines between headings and their entry text, and without any
indentation, headings and entry text on varying levels tends to blend
together, making for very poor readability.  Disabling this setting
would make this problem worse.

Generally, I don't think "beginners are bad at" is a good argument for
changing defaults.  No one is "good at" Emacs and Org when they first
come to it.  There's probably room for improving the defaults, but we
should not necessarily make changes based on guessing what brand-new
users are most likely to want.  Emacs and Org are, thankfully, generally
free from the trend of aiming software at those who have never used it
before.  Instead, it tends to call users to learn more and aspire to
mastery, which is more useful and empowering in the long run.




Re: org-startup-truncated default should be nil [legibility 2/6]

2020-02-03 Thread Adam Porter
Texas Cyberthal  writes:

> #+begin_src elisp
> (org-startup-truncated nil)
> #+end_src
>
> Line truncation is necessary for code but anathema for prose. Prose
> lines need visual wrap as windows resize, so that texts can be
> compared easily.
>
> Advanced Org uses such as large tables require line truncation. Tables
> are a code-like fixed-pitch feature.
>
> Users will write a paragraph of prose longer than the screen well
> before they discover a need for line truncation, such as long lines of
> code or wide tables. Users who need line truncation are likely to know
> about it, whereas users who need line truncation off are unlikely to
> know what it's called.
>
> Learning about line truncation is an unnecessary hurdle for beginners.
> Therefore the default should be nil.

visual-line-mode and toggle-truncate-lines are basic Emacs commands that
all users should learn early.  As well, many users prefer to use filled
paragraphs rather than visual wrapping.  And we shouldn't prioritize
prose above other uses. So this default should probably not be changed.

What would be useful would be if Emacs/Org could be configured to wrap
prose lines but not, e.g. tables and code blocks.  I don't think such
functionality exists in Emacs now, but here's a new package that may be
relevant: https://github.com/luisgerhorst/virtual-auto-fill

As well, it might be good to discuss on emacs-devel whether a feature
could be developed to truncate/wrap lines selectively; maybe
font-locking could be used to apply text properties to disable wrapping
dynamically (assuming that a feature could be developed to wrap based on
a certain text property).  Then we could have the best of both worlds,
and solve an existing problem, viz. that tables and code gets wrapped
when visual-line-mode is enabled.




Re: Defaults for noobs, dotfiles for vets [legibility 1/6]

2020-02-03 Thread Adam Porter
Texas Cyberthal  writes:

> Beginners spend a while learning to use Emacs as a simple text editor
> before they're able to do anything more advanced. Their ability to
> intelligently customize is minimal. Meanwhile experts have automated
> dotfile deployment, so defaults are almost irrelevant to them.
> Therefore defaults should be set for inexperienced users.

Defaults are relevant for all users, because if you change the default
of a setting that an "experienced user" uses the default for, he will
have to change that setting in his config.  New users come to Emacs/Org
a few at a time; changing the defaults would affect all existing users
at once.  Therefore changing the defaults should be very carefully
considered, and they should not reflect one user's beliefs about what
best suits other users.

> Inexperienced users will mostly use Org for longform prose, since they
> haven't learned its database functions yet. Since Org aspires to be a
> personal info manager, it should prioritize prose presentation above
> code conventions.

Org is not intended more for prose writing than for other uses.  We
should not prioritize one such use above others.

> Concerns about terminal impact appear to be moot, since terminal
> ignores most font settings.

Terminals can display colors, underlines, italics, and bold text, and
terminal appearance should not be ignored or de-prioritized.




Re: Make code elements in prose unobtrusive [legibility 6/6]

2020-02-03 Thread Adam Porter
As Tim said, this is really a matter for theming.  There are several
themes and example configs available that make Org buffers "pretty".
For example:

https://github.com/kunalb/poet
https://github.com/jonnay/org-beautify-theme
https://lepisma.xyz/2017/10/28/ricing-org-mode/

As well, faces are easy to customize using:

  M-x customize-apropos-faces RET org RET

There may be improvements to be made, but the defaults shouldn't be set
to match the preferences of any one user.  Remember that people have
been using Org for years, and theming and faces are very personal.  ;)




Re: Provide org-insert-subitem

2020-02-02 Thread Adam Porter
Bastien  writes:

> `org-insert-subheading' and `org-insert-todo-subheading' are not used
> anywhere in Org's code.  Do you them?  How?
>
> I'm more inclined to delete these commands since they have no binding
> than to add an `org-insert-subitem'.
>
> Hitting  then  seems swift and handy enough.

Please do not delete org-insert-subheading!  I use it every day and have
for years.  :) It would be much less convenient to have to use two
commands.

BTW, in my version of Org, org-insert-subheading works on both list
items and subheadings, so there's no need for a separate
org-insert-subitem command:

  Insert a new subheading and demote it.
  Works for outline headings and for plain lists alike.




Re: org-superstar-mode: A re-imagining of org-bullets with new features

2020-02-02 Thread Adam Porter
Hi D,

This looks fantastic!  Great work!  I sent you a quick suggestion on the
issue tracker.  Let's get this on MELPA ASAP!  :)




Re: can't sign in to code.orgmode.org

2020-01-28 Thread Adam Porter
"Tyler Smith"  writes:

> I am trying to set up an account with code.orgmode.org. I have already
> done this, but when I try to sign in, I get an error about incorrect
> username or password. I have clicked the link to send a password reset
> several times this morning, but no email has shown up in my account,
> or in my spam folder.

I also tried to create an account the other day (I thought I already had
one, but apparently not), and I never received the confirmation email.




Re: New page https://orgmode.org/worg/donate.html

2020-01-28 Thread Adam Porter
FYI, Jonas Bernoulli also maintains a similar page for Emacs in general:

https://github.com/tarsius/elisp-maintainers




Re: [RFC] C-c C-c in agenda

2020-01-28 Thread Adam Porter
Marco Wahl  writes:

> For some days now C-c C-c disables column view in Org files.  This helps
> me a bit and never got in my way.  And I thought it would be quite
> natural and consistent to use this binding for the agenda too.
>
> What do you think about all that?

Hi Marco,

I've always had the impression that the "C-c C-c" binding was intended
to do the most obviously useful or natural action in the current
context.  For example, in a capture or log buffer, it completes the
capture.  With point on a #+ line, it resets buffer properties
accordingly.

I don't use column view very often, so I may be biased, but anyway: in
the general context of an Agenda buffer, I don't feel like enabling or
disabling column view is the most obviously useful or natural thing to
do, so "C-c C-c" doesn't seem like an appropriate binding to me.




Re: org-word-count exemptions

2020-01-25 Thread Adam Porter
There are various solutions floating around.  Here's one way:

(defun ap/org-count-words ()
  "If region is active, count words in it; otherwise count words in current 
subtree."
  (interactive)
  (if (use-region-p)
  (funcall-interactively #'count-words-region (region-beginning) 
(region-end))
(org-with-wide-buffer
 (cl-loop for (lines words characters)
  in (org-map-entries
  (lambda ()
(unpackaged/org-forward-to-entry-content 'unsafe)
(let ((end (org-entry-end-position)))
  (list (count-lines (point) end)
(count-words (point) end)
(- end (point)
  nil 'tree)
  sum lines into total-lines
  sum words into total-words
  sum characters into total-characters
  finally do (message "Subtree \"%s\" has %s lines, %s words, and 
%s characters."
  (org-get-heading t t) total-lines total-words 
total-characters)

(defun unpackaged/org-forward-to-entry-content ( unsafe)
  "Skip headline, planning line, and all drawers in current entry.
If UNSAFE is non-nil, assume point is on headline."
  (unless unsafe
;; To improve performance in loops (e.g. with `org-map-entries')
(org-back-to-heading))
  (cl-loop for element = (org-element-at-point)
   for pos = (pcase element
   (`(headline . ,_)
(org-element-property :contents-begin element))
   (`(,(or 'planning 'property-drawer 'drawer) . ,_)
(org-element-property :end element)))
   while pos
   do (goto-char pos)))




Re: [ANN] org-ql 0.4 released

2020-01-25 Thread Adam Porter
Michael Alan Dorman  writes:

> On the other hand, I *also* don't assume that maintainers are incapable
> of making a reasonable assessment of the stability of their packages, or
> of making a personal choice to try to maintain API compatibility in some
> sensible way, and so forth.

If it were only a matter of maintainers assessing the stability of
individual packages, there would be no problem.  The problem is that
some packages depend on other packages, and their maintainers don't
coordinate the tagging of stable versions.  Everyone does their own
thing in their own time.  MELPA Stable can't solve that.

> And you know what: my personal experience over the last five years
> hasn't been subject to the problems you identify; perhaps I'm just
> lucky.

It works pretty well, except when it doesn't.

> Nevertheless, my experience leads me to be of the opinion that
> abolishing melpa-stable would reek of making the perfect the enemy of
> the good

AFAICT no good comes from using MELPA Stable.

> but I think that it is still an improvement to give maintainers *some*
> strategy for trying to manage their packages and their dependencies
> and communicate all this to their users

Even the most widely used, most impressive packages, like Magit and
Helm, don't consistently tag stable versions and don't use actual
semantic versioning.  There are no rules, so even if a few developers
were disciplined in their development and tagging, it would not justify
a user using MELPA Stable, because the other packages on it would not
live up to the same standards.  It doesn't offer what you seem to think
it does.

> rather than consigning every emacs user to doing individual curation
> for every single package they ever use.

That's not necessary.  Just put ~/.emacs.d/elpa in version control, and
when your config and package versions seem to be working, commit
everything.  Next time you upgrade packages, if something breaks and you
don't have time to fix it, rollback to what works and try again later.
If everything seems to work, commit the upgraded packages.  It's very
simple, and unlike MELPA Stable, it will give you actual stability.

> Given your position, though, could I suggest that you at least remove
> dependencies from your packgaes that feature versions that can only make
> sense with melpa-stable?  That's what ultimately started this: the fact
> that your new release of org-ql depends on a version of org-super-agenda
> that *looks* like you care about melpa stable.

I care about stability, not MELPA Stable.  It's your choice to use MELPA
Stable, and you're free to upgrade or downgrade individual packages to
work around such occasional, temporary breakage caused by it--the pieces
are yours to keep.  I'm sorry for any inconvenience, but your config is
up to you.




Re: [ANN] org-ql 0.4 released

2020-01-24 Thread Adam Porter
Tim Cross  writes:

> I don't disagree with most of what you write. I do think a big part of
> the problem is inconsistency and poor practices by some maintainers
> which is at the hart of the issue. Sometimes it seems that package
> maintainers put too much emphasis on getting the latest package out and
> forget about the stability and dependencies that users have.
>
> All of this leaves me wondering why the ELPA system doens't adopt a
> semantic versioning scheme and configure the repositories to
> keep/maintain previous versions. Emacs was very late to the whole
> 'package' concept and it is a little disappointing that more time wasn't
> invested in understanding the challenges and solutions implemented by
> other systems like deb, rpm, CPAN, Java, ruby, python etc. There is
> little unique to the Emacs environment that other environments haven't
> had to resolve one way or the other.  

The problems you identified in the first paragraph are why the solution
identified in the second paragraph doesn't work (for this case; I like
SemVer in general).

> However, a semantic version does provide more information than
> something like version 20200123, which just tells me the release
> date. At least with complaint semantic versions I can have a better
> idea as to whether the changes are just a bug fix, an enhancement or
> major API changes that may break existing dependencies.

Yes, and that's why I like it, too.  But we can't make other developers
use it.  Even if MELPA required SemVer-like numbering, nothing would
stop package maintainers from incrementing major-only version numbers.
It's their code.

Developing with proper use of semantic versioning is a discipline that
requires extra diligence.  It's rarely more fun, and for most Emacs
packages, it's not worth the trouble.  Most packages are dependents
rather than dependencies, leaves at the ends of the branches, and they
can be freely upgraded without breaking anything else.  Most packages'
interoperability with other packages is minor.

If SemVer were required, MELPA would probably have 5-10% of the packages
it does today.  The lax, welcoming approach used by MELPA has drawbacks,
but it also has tremendous benefits, and I think it's to credit for much
of the vibrancy of the Emacs package "ecosystem" and community today.

The problem I'm writing about here is that users' perception of MELPA
Stable doesn't match the reality.  Discussions about how to change MELPA
Stable and MELPA versioning for the better have been going on for years.
Ultimately that doesn't matter, because package authors can do whatever
they want.  We should help users understand and accept the technical
reality--and MELPA Stable misleads them, so it should be removed.  As I
posted in my proposal on the MELPA tracker, we can pursue better
technical solutions then, ones that may be more in line with the
limitations of the platform.

If you're interested in the topic, please join the discussions on the
MELPA tracker.




Re: [ANN] org-ql 0.4 released

2020-01-24 Thread Adam Porter
Michael Alan Dorman  writes:

>> Hi friends,
>>
>> FYI, I've released org-ql 0.4.  It includes many improvements since 0.3.
>>
>> https://github.com/alphapapa/org-ql
>
> It would be nice if you could do a stable release of org-super-agenda so
> that it could be installed from melpa-stable...

Comments like yours lead me to the conclusion that MELPA Stable needs to
be abolished.  I have been a proponent of the idea of MELPA Stable, so I
don't say that lightly.

I'll assume that you don't know what the technical issues are and offer
an explanation.  Briefly:

+ MELPA Stable is nothing like what one might assume it's intended to be
  like, e.g. Debian Stable or Debian Testing.  It provides none of the
  benefits that Debian Stable and Testing provide.

+ MELPA Stable is, just like "regular" MELPA, a "rolling" collection of
  packages developed without any coordination between maintainers.

+ The only difference is that MELPA Stable contains whatever versions of
  packages that their maintainers have decided to tag with a version
  number, rather than the latest commit to the master branch.  These
  versions are not necessarily better, more stable, more reliable, or
  more trustworthy than the untagged versions which appear in "regular"
  MELPA.

+ Due to the lack of coordination between dependencies and their APIs,
  version conflicts and breakage are a regular occurrence.  For example,
  if package A depends on package B, and package B makes an API change
  and tags a new MELPA Stable release, users of package A's MELPA Stable
  version will see package A cease to work properly until package A, not
  only commits a fix, but tags a new MELPA Stable version containing the
  fix.  Since packages A and B do not share the same development
  schedule, it is likely that their tagged-version release schedules
  will not synchronize well.

  If you are familiar with Debian, imagine if any upstream changes were
  automatically pushed to Testing despite any freeze that might be in
  place.  It would be virtually impossible to complete a freeze and make
  a new stable release, and Testing and Stable would cease to be useful,
  leaving only Unstable as a usable target.  This is the situation
  between "regular" MELPA and MELPA Stable.

For my packages, I tag stable versions for a few reasons:

+ To help users track changes in the changelog.

+ To help me separate new, possibly bug-introducing changes from
  working, debugged code.

+ To help packagers in systems like Debian and Guix, who package stable
  versions of some Elisp packages--and who, in so doing, take
  responsibility for breakage.

Now, I sympathize with not wanting to be vulnerable to potential
breakage caused by the uncoordinated release of changes to packages on
"regular" MELPA.  That is a real problem.  But the solution is not to
use MELPA Stable.  The solution is to take charge of what packages you
upgrade and when, rather than being at the mercy of whatever commits
happen to be in MELPA at the moment.

For myself, I commit the ~/.emacs.d/elpa directory to Git with the rest
of my config, and I upgrade packages intentionally.  If breakage
happens, I can easily revert and deal with it later.  Other users use
alternative package managers, like Borg or Straight or Quelpa, which
pull changes directly from Git repos and allow pinning to commits, tags,
etc.

So, for yourself, I can only recommend that you abandon MELPA Stable and
install packages by other means.  If you don't have the time or
inclination to redo your whole config like that, then just use something
like Quelpa to install the current version of org-super-agenda directly.
It's a couple lines of use-package in your config, and you can upgrade
it manually from then on, e.g. with
.
As always, your Emacs config is up to you.

Now, I'm off to to the discussions on MELPA's tracker to add my vote to
abolish MELPA Stable, or to at least allow packages to opt-out of it.




[ANN] org-ql 0.4 released

2020-01-23 Thread Adam Porter
Hi friends,

FYI, I've released org-ql 0.4.  It includes many improvements since 0.3.

https://github.com/alphapapa/org-ql

Thanks,
Adam




Re: [O] Orgmode Latex Export with Babel/LilyPond

2020-01-11 Thread adam
On Sun, 2020-01-12 at 10:43 +1300, adam wrote:
> On Sun, 2020-01-12 at 09:04 +1300, adam wrote:
> > 
> > On Sat, 2020-01-11 at 12:30 -0300, Jonathan Gregory wrote:
> > > 
> > > 
> > > 
> > > On 11 Jan 2020, adam  wrote:
> > > 
> > > > 
> > > > 
> > > > 
> > > > Still no success in tangling the examples  modal-cycle.org  
> > > > modal-cycle2.org  
> > > > shown here, 
> > > > https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html
> > > >  
> > > > 
> > > > My current problem is Emacs rejecting the addition of either Lilypond 
> > > > or 
> > > > lilypond, in the  org-babel-do-load-languages  
> > > > 
> > > >    (org-babel-do-load-languages
> > > >  'org-babel-load-languages
> > > >  '(
> > > >    (emacs-lisp . t)
> > > >    (shell . t)
> > > >    (org . t)
> > > >    (Lilypond . t)
> > > >    )) 
> > > > 
> > > > including either in the last line causes an error at Emacs startup, 
> > > > reported as, 
> > > > 
> > > >    Warning (initialization): An error occurred while loading 
> > > > ‘/home/user/.emacs’:
> > > >    Symbol's value as variable is void:  > > > 
> > > > 
> > > > Earlier in my .emacs init file, I had hopefully defined lilypond, thus 
> > > > 
> > > >    (setq ly-nix-ly-path "lilypond")
> > > > 
> > > >    (add-to-list 'load-path "/usr/share/emacs/site-lisp/") 
> > > > 
> > > >    (autoload 'LilyPond-mode "lilypond-mode")
> > > > 
> > > >    (setq auto-mode-alist
> > > >  (cons '("\\.ly$" . LilyPond-mode) auto-mode-alist))
> > > > 
> > > >    (add-hook 'LilyPond-mode-hook (lambda () (turn-on-font-lock))) 
> > > > 
> > > > 
> > > > In  /usr/share/emacs/site-lisp/   many lilypond related .el files 
> > > > are located,
> > > > 
> > > >    lilypond-font-lock.el
> > > >    lilypond-indent.el
> > > >    lilypond-init.el
> > > >    lilypond-mode.el
> > > >    lilypond-song.el
> > > >    lilypond-what-beat.el
> > > >    lilypond-words.el
> > > >    ltx-help.el
> > > >    ob-lilypond.el
> > > >    ob-Lilypond.el
> > > >    ob-lisp.el
> > > >    org-tests.el
> > > > 
> > > > 
> > > > $ which lilypond is unhelpful,
> > > > 
> > > >    /usr/bin/lilypond 
> > > > 
> > > > 
> > > > The lilypond installation is at, 
> > > > 
> > > >    /usr/share/lilypond/2.18.2/ 
> > > > 
> > > > 
> > > > Any advice or suggestions would be most welcome. 
> > > Version 9.1.9 comes with ob-lilypond.el. There's no ob-babel-lilypond.el 
> > > AFAIK.
> > > Also,
> > > where is ly-nix-ly-path and other ly-* variables defined? I don't see 
> > > these
> > > variables.
> > > 
> > Thank you. I'll look inside ob-lilypond.el  for clues, variables to be 
> > defined.  
> > 
> > 
> > Org-mode version 9.1.9 (release_9.1.9-65 ...) @ 
> > /usr/share/emacs/26.3/lisp/org 
> > on Ubuntu 18.04
> > 
> > $ find / -name "ob*.el" locates only the ob-lilypond.el  I downloaded 
> > from github
> >  
> >  
> > Maybe I need a (require 'lilypond) somewhere, I was thinking. 
> > 
> > 
> > Its a new system here. Emacs was installed with Ubuntu's software manager, 
> > lilypond 
> > was installed with $ sudo apt install lilypond     Neither were built from 
> > source. 
> > 
> 
> OK, my bad.  When I look inside  ob-lilypond.el  I find I pulled a page of 
> markup
> stuff. 
> Will grab a proper  ob-lilypond.el    That will improve matters.   


Improvement with correct  ob-lilypond.el   Now the (org-babel-do-load-languages 
..) 
doesn't cause Emacs to report error at Emacs start-up. 

Presently, with examples  modal-cycle.org  modal-cycle-2.org  
modes-in-key-of-C.org 
I can  C-c C-e l p  export to PDF, but there's no music symbols. 

Also I have no M-x ly-*  commands available. 

Org Customize Option, babel, lilypond, for  org-babel-lilypond-commands  is set 
to  nil   





Re: [O] Orgmode Latex Export with Babel/LilyPond

2020-01-11 Thread adam
On Sun, 2020-01-12 at 09:04 +1300, adam wrote:
> On Sat, 2020-01-11 at 12:30 -0300, Jonathan Gregory wrote:
> > 
> > 
> > On 11 Jan 2020, adam  wrote:
> > 
> > > 
> > > 
> > > Still no success in tangling the examples  modal-cycle.org  
> > > modal-cycle2.org  
> > > shown here, 
> > > https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html 
> > > 
> > > My current problem is Emacs rejecting the addition of either Lilypond or 
> > > lilypond, in the  org-babel-do-load-languages  
> > > 
> > >    (org-babel-do-load-languages
> > >  'org-babel-load-languages
> > >  '(
> > >    (emacs-lisp . t)
> > >    (shell . t)
> > >    (org . t)
> > >    (Lilypond . t)
> > >    )) 
> > > 
> > > including either in the last line causes an error at Emacs startup, 
> > > reported as, 
> > > 
> > >    Warning (initialization): An error occurred while loading 
> > > ‘/home/user/.emacs’:
> > >    Symbol's value as variable is void:  > > 
> > > 
> > > Earlier in my .emacs init file, I had hopefully defined lilypond, thus 
> > > 
> > >    (setq ly-nix-ly-path "lilypond")
> > > 
> > >    (add-to-list 'load-path "/usr/share/emacs/site-lisp/") 
> > > 
> > >    (autoload 'LilyPond-mode "lilypond-mode")
> > > 
> > >    (setq auto-mode-alist
> > >  (cons '("\\.ly$" . LilyPond-mode) auto-mode-alist))
> > > 
> > >    (add-hook 'LilyPond-mode-hook (lambda () (turn-on-font-lock))) 
> > > 
> > > 
> > > In  /usr/share/emacs/site-lisp/   many lilypond related .el files 
> > > are located,
> > > 
> > >    lilypond-font-lock.el
> > >    lilypond-indent.el
> > >    lilypond-init.el
> > >    lilypond-mode.el
> > >    lilypond-song.el
> > >    lilypond-what-beat.el
> > >    lilypond-words.el
> > >    ltx-help.el
> > >    ob-lilypond.el
> > >    ob-Lilypond.el
> > >    ob-lisp.el
> > >    org-tests.el
> > > 
> > > 
> > > $ which lilypond is unhelpful,
> > > 
> > >    /usr/bin/lilypond 
> > > 
> > > 
> > > The lilypond installation is at, 
> > > 
> > >    /usr/share/lilypond/2.18.2/ 
> > > 
> > > 
> > > Any advice or suggestions would be most welcome. 
> > Version 9.1.9 comes with ob-lilypond.el. There's no ob-babel-lilypond.el 
> > AFAIK. Also,
> > where is ly-nix-ly-path and other ly-* variables defined? I don't see these 
> > variables.
> > 
> Thank you. I'll look inside ob-lilypond.el  for clues, variables to be 
> defined.  
> 
> 
> Org-mode version 9.1.9 (release_9.1.9-65 ...) @ 
> /usr/share/emacs/26.3/lisp/org 
> on Ubuntu 18.04
> 
> $ find / -name "ob*.el" locates only the ob-lilypond.el  I downloaded 
> from github
>  
>  
> Maybe I need a (require 'lilypond) somewhere, I was thinking. 
> 
> 
> Its a new system here. Emacs was installed with Ubuntu's software manager, 
> lilypond 
> was installed with $ sudo apt install lilypond     Neither were built from 
> source. 
> 


OK, my bad.  When I look inside  ob-lilypond.el  I find I pulled a page of 
markup stuff. 
Will grab a proper  ob-lilypond.el    That will improve matters.   





Re: [O] Orgmode Latex Export with Babel/LilyPond

2020-01-11 Thread adam
On Sat, 2020-01-11 at 12:30 -0300, Jonathan Gregory wrote:
> 
> On 11 Jan 2020, adam  wrote:
> 
> > 
> > Still no success in tangling the examples  modal-cycle.org  
> > modal-cycle2.org  
> > shown here, 
> > https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html 
> > 
> > My current problem is Emacs rejecting the addition of either Lilypond or 
> > lilypond, in the  org-babel-do-load-languages  
> > 
> >    (org-babel-do-load-languages
> >  'org-babel-load-languages
> >  '(
> >    (emacs-lisp . t)
> >    (shell . t)
> >    (org . t)
> >    (Lilypond . t)
> >    )) 
> > 
> > including either in the last line causes an error at Emacs startup, 
> > reported as, 
> > 
> >    Warning (initialization): An error occurred while loading 
> > ‘/home/user/.emacs’:
> >    Symbol's value as variable is void:  > 
> > 
> > Earlier in my .emacs init file, I had hopefully defined lilypond, thus 
> > 
> >    (setq ly-nix-ly-path "lilypond")
> > 
> >    (add-to-list 'load-path "/usr/share/emacs/site-lisp/") 
> > 
> >    (autoload 'LilyPond-mode "lilypond-mode")
> > 
> >    (setq auto-mode-alist
> >  (cons '("\\.ly$" . LilyPond-mode) auto-mode-alist))
> > 
> >    (add-hook 'LilyPond-mode-hook (lambda () (turn-on-font-lock))) 
> > 
> > 
> > In  /usr/share/emacs/site-lisp/   many lilypond related .el files 
> > are located,
> > 
> >    lilypond-font-lock.el
> >    lilypond-indent.el
> >    lilypond-init.el
> >    lilypond-mode.el
> >    lilypond-song.el
> >    lilypond-what-beat.el
> >    lilypond-words.el
> >    ltx-help.el
> >    ob-lilypond.el
> >    ob-Lilypond.el
> >    ob-lisp.el
> >    org-tests.el
> > 
> > 
> > $ which lilypond is unhelpful,
> > 
> >    /usr/bin/lilypond 
> > 
> > 
> > The lilypond installation is at, 
> > 
> >    /usr/share/lilypond/2.18.2/ 
> > 
> > 
> > Any advice or suggestions would be most welcome. 
> Version 9.1.9 comes with ob-lilypond.el. There's no ob-babel-lilypond.el 
> AFAIK. Also,
> where is ly-nix-ly-path and other ly-* variables defined? I don't see these 
> variables.
> 

Thank you. I'll look inside ob-lilypond.el  for clues, variables to be defined. 
 


Org-mode version 9.1.9 (release_9.1.9-65 ...) @ /usr/share/emacs/26.3/lisp/org 
on Ubuntu 18.04

$ find / -name "ob*.el" locates only the ob-lilypond.el  I downloaded from 
github
 
 
Maybe I need a (require 'lilypond) somewhere, I was thinking. 


Its a new system here. Emacs was installed with Ubuntu's software manager, 
lilypond 
was installed with $ sudo apt install lilypond     Neither were built from 
source. 






Re: [O] Orgmode Latex Export with Babel/LilyPond

2020-01-11 Thread adam
Still no success in tangling the examples  modal-cycle.org  modal-cycle2.org  
shown here, 
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html 

My current problem is Emacs rejecting the addition of either Lilypond or 
lilypond, in the  org-babel-do-load-languages  

   (org-babel-do-load-languages
     'org-babel-load-languages
     '(
       (emacs-lisp . t)
       (shell . t)
       (org . t)
       (Lilypond . t)
       )) 

including either in the last line causes an error at Emacs startup, reported 
as, 

   Warning (initialization): An error occurred while loading 
‘/home/user/.emacs’:
   Symbol's value as variable is void: 

Re: [O] Orgmode Latex Export with Babel/LilyPond

2020-01-10 Thread adam
On Sat, 2019-04-20 at 14:04 +0200, Jakob Schöttl wrote:
> Hi,
> 
> I'm trying (second attempt), to setup orgmode to export PDFs with images 
> generated by Babel/LilyPond.
> 
> I followed the setup instructions here:
> 
> https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html
> 
> I have
> 
> a recent emacs (Arch Linux),
> 
> ~/.emacs file with
> 
> (org-babel-do-load-languages
>    'org-babel-load-languages
>    '((lilypond t)))
> 
> (although I saw many other snippets where there is a "." between the 
> (lilypond t)). I tried both variants.
> 
> I tried also tried (require 'lilypond) instead 
> org-babel-do-load-languages which caused an error.
> 
> I pressed C-c C-e l p -> "PDF file produced."
> 
> But no images are generated and no images appear in the PDF. Only plain 
> source code.
> 
> Any ideas?
> Thank you!
> 
> - Jakob
> 
> 

I too, find the Setup instructions at 
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html 
difficult to interpret. 

This page says under Setup; 
- must be on a very recent version of org-mode 
- ob-lilypond is also included in the latest Org-mode by default (it seems its 
not)
- add lilypond to your list of babel languages 


My Org-mode version 9.1.9  Emacs version 26.3 

lilypond has been added to my list of babel languages 

I found lilypond-mode.el  and syntax is colored, that seems to work 

I have grabbed recent  ob-babel-lilypond.el  from github, and put 
that into /usr/share/emacs/site-lisp/  


How or where do I load  ob-babel-lilypond.el   ? 

Presently, I cannot tangle the org lilypond examples, and have no M-x ly-*  
commands. 

Raw text Lilypond will compile and output OK. And org LaTeX export is working. 





Re: Long links

2020-01-04 Thread Adam Porter
Steven Penny  writes:

> yes, and I would have never made this point had you not insisted on
> starting an off topic conversation.
>
> Next we know you will say why someone is using spaces over tabs, or
> emac over vim, or red over blue bikeshed. Stop.

This rude one-upsmanship is uncalled for.  The gentleman attempted to
offer you a solution you did not appear to be aware of.  If, in fact,
one of you misunderstood the other, or he offered you a solution you
can't use, no harm has been done--thank him for his offer and move on.
Or, if you can't be kind, let it be unanswered.




Re: How to capture export prepended header numbering

2019-12-30 Thread Adam Porter
Someone reminded me that Org has org-num-mode now, so please disregard
all of that.  At least it was good exercise.




Re: How to capture export prepended header numbering

2019-12-30 Thread Adam Porter
Adam Porter  writes:

> There is no built-in way to do that, and no way independent of
> org-export to get the numbers, AFAIK.
>
> Here's some ugly old code that shows outline numbering as overlays in an
> Org buffer.  It doesn't update automatically, so you have to run it
> again when the outline changes.  But it seems to work well.  It uses
> dash.el and let-alist, in case you don't have them loaded.

Please do disregard that monstrosity.  I rewrote it in a much simpler
way.  It seems fast on a reasonably large Org buffer.  It doesn't
account for org-indent-mode or org-bullets, but that wouldn't be too
hard to fix, I think.

No third-party packages are required.  See attached file, or
<https://github.com/alphapapa/unpackaged.el#outline-number-overlays>.



november-0ac22.el
Description: org-outline-numbers rewritten


Re: How to capture export prepended header numbering

2019-12-30 Thread Adam Porter
FYI, I tidied the code a tiny bit and posted it here:

https://github.com/alphapapa/unpackaged.el#outline-number-overlays




Re: How to capture export prepended header numbering

2019-12-30 Thread Adam Porter
There is no built-in way to do that, and no way independent of
org-export to get the numbers, AFAIK.

Here's some ugly old code that shows outline numbering as overlays in an
Org buffer.  It doesn't update automatically, so you have to run it
again when the outline changes.  But it seems to work well.  It uses
dash.el and let-alist, in case you don't have them loaded.

mike-0ac22.el
Description: ap/org-outline-numbers


Re: refile captured to all opened Org buffer files as targets

2019-12-26 Thread Adam Porter
stardiviner  writes:

> I recently created an org-capture template for elfeed, it is finished. Now I
> have an idea is to refile it to all currently opened Org buffer files. So I
> created an function for ~org-refile-targets~ variable.
>
> #+begin_src emacs-lisp
> (defun org-refile-targets-all-files ()
>   "Use all currently opened Org buffer files as org-refile targets."
>   (mapcar 'buffer-file-name
>   (seq-filter (lambda (buffer) (if-let (file (buffer-file-name 
> buffer)) (f-ext? file "org"))) ; filter Org buffers
>   (buffer-list
> #+end_src
>
>
> Then set ~org-refile-targets~ to use upper custom function
>
> #+begin_src emacs-lisp :eval no
> (setq org-refile-targets '((nil :maxlevel . 3) ; current buffer headlies
>(org-agenda-files :maxlevel . 2) ; agenda files 
> headlines
>(org-refile-targets-all-files :maxlevel . 3) ; all 
> opened Org buffer files headlines
>))
> #+end_src
>
> Can I add this as a patch to Org Mode repository?

org-buffer-list is a compiled Lisp function in ‘org.el’.

(org-buffer-list  PREDICATE EXCLUDE-TMP)

Return a list of Org buffers.
PREDICATE can be ‘export’, ‘files’ or ‘agenda’.

export   restrict the list to Export buffers.
filesrestrict the list to buffers visiting Org files.
agenda   restrict the list to buffers visiting agenda files.

If EXCLUDE-TMP is non-nil, ignore temporary buffers.





  1   2   3   4   5   6   7   8   9   >