org-word-count exemptions

2020-01-24 Thread Sharon Kimble

If I have a drawer titled 'mydrawer', how can I exempt it and its
contents from word-count please? This is using wc-mode and also in
org-word-count too.

Thanks
Sharon.
-- 
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
DrugFacts = https://www.drugfacts.org.uk
Debian 10.2, fluxbox 1.3.7, emacs 26.3, org 9.3.1


signature.asc
Description: PGP signature


Re: [RFC PATCH] Changes to pop-up source buffers

2020-01-24 Thread Kyle Meyer
Kyle Meyer  writes:
>> Subject: [PATCH] org-src: Add option 'plain to org-src-window-setup
> I'll wait another day or so for others to comment before applying.

I've applied this patch (with the mentioned tweaks) and the second patch
(with a slight expansion of the commit message).

Thanks.



Re: [ANN] org-ql 0.4 released

2020-01-24 Thread Michael Alan Dorman
Adam,

I do recognize that melpa-stable is not in any practical way curated,
guaranteed, cross-tested, etc.---and that emacs' packaging doesn't even
necessarily provide what might be required for anyone to try to do any
of that.

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.

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.

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---breakage can happen, and some things on it are no better than
whatever happens to be up on melpa, and it's unlikely to ever improve to
be a perfectly curated set of package versions, and got knows some stuff
lags behind enormously...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, rather than
consigning every emacs user to doing individual curation for every
single package they ever use.

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.

Mike.

Adam Porter  writes:
> 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
> 

Org-ref issues

2020-01-24 Thread Marvin M. Doyley
Hi there,

I just upload org-ref on my system via melpa and get the following error when I 
issue the command doi-utils-add-bibtex-entry-from-doi

Symbol’s function definition is void: org-ref-possible-bibfiles


Does anybody know how to resolve this

Thanks 

M

Here is the backtrace

Debugger entered--Lisp error: (void-function org-ref-possible-bibfiles)
  org-ref-possible-bibfiles()
  doi-utils-add-bibtex-entry-from-doi("10.1109/TUFFC.2019.2961875")
  funcall-interactively(doi-utils-add-bibtex-entry-from-doi 
"10.1109/TUFFC.2019.2961875")
  call-interactively(doi-utils-add-bibtex-entry-from-doi record nil)
  command-execute(doi-utils-add-bibtex-entry-from-doi record)
  helm-M-x-execute-command(doi-utils-add-bibtex-entry-from-doi)
  helm-execute-selection-action-1()
  helm-execute-selection-action()
  helm-internalname . "Emacs Commands history") (candidates . 
#f(compiled-function () #)) (keymap keymap (keymap (13 . 
helm-confirm-and-exit-minibuffer)) keymap (21 . helm-M-x-universal-argument) 
keymap (127 . delete-backward-char) (27 keymap (13 . helm-cr-empty-string)) 
(C-return . helm-cr-empty-string) keymap (tab . helm-execute-persistent-action) 
(26 . helm-select-action) (f13 lambda nil (interactive) (helm-select-nth-action 
12)) (f12 lambda nil (interactive) (helm-select-nth-action 11)) (f11 lambda nil 
(interactive) (helm-select-nth-action 10)) (f10 lambda nil (interactive) 
(helm-select-nth-action 9)) (f9 lambda nil (interactive) 
(helm-select-nth-action 8)) (f8 lambda nil (interactive) 
(helm-select-nth-action 7)) (f7 lambda nil (interactive) 
(helm-select-nth-action 6)) (f6 lambda nil (interactive) 
(helm-select-nth-action 5)) (f5 lambda nil (interactive) 
(helm-select-nth-action 4)) (f4 lambda nil (interactive) 
(helm-select-nth-action 3)) (f3 lambda nil (interactive) 
(helm-select-nth-action 2)) (f2 lambda nil (interactive) 
(helm-select-nth-action 1)) (menu-bar keymap (help-menu keymap (describe keymap 
(describe-mode . helm-help (help keymap (109 . helm-help)) (23 . 
#f(compiled-function () (interactive nil) #)) (f1 lambda 
nil (interactive) (helm-select-nth-action 0)) (8 keymap (109 . helm-help) (104 
. undefined) (8 . undefined) (99 . helm-customize-group) (4 . 
helm-enable-or-switch-to-debug)) (20 . helm-toggle-resplit-and-swap-windows) 
(C-tab . undefined) (67108897 . helm-toggle-suspend-update) (3 keymap (57 . 
helm-execute-selection-action-at-nth-+9) (56 . 
helm-execute-selection-action-at-nth-+8) (55 . 
helm-execute-selection-action-at-nth-+7) (54 . 
helm-execute-selection-action-at-nth-+6) (53 . 
helm-execute-selection-action-at-nth-+5) (52 . 
helm-execute-selection-action-at-nth-+4) (51 . 
helm-execute-selection-action-at-nth-+3) (50 . 
helm-execute-selection-action-at-nth-+2) (49 . 
helm-execute-selection-action-at-nth-+1) (63 . helm-help) (110 . 
#f(compiled-function () (interactive nil) #)) (108 . 
helm-display-line-numbers-mode) (62 . helm-toggle-truncate-line) (21 . 
helm-refresh) (6 . helm-follow-mode) (9 . helm-copy-to-buffer) (11 . 
helm-kill-selection-and-quit) (25 . helm-yank-selection) (37 . 
helm-exchange-minibuffer-and-header-line) (95 . helm-toggle-full-frame) (45 . 
helm-swap-windows)) (67108987 . helm-enlarge-window) (67108989 . 
helm-narrow-window) (19 . undefined) (24 keymap (57 . 
helm-execute-selection-action-at-nth-+9) (56 . 
helm-execute-selection-action-at-nth-+8) (55 . 
helm-execute-selection-action-at-nth-+7) (54 . 
helm-execute-selection-action-at-nth-+6) (53 . 
helm-execute-selection-action-at-nth-+5) (52 . helm-select-4rd-action) (51 . 
helm-select-3rd-action) (50 . helm-select-2nd-action) (49 . 
helm-execute-selection-action-at-nth-+1) (2 . 
helm-resume-list-buffers-after-quit) (98 . 
helm-resume-previous-session-after-quit) (6 . helm-quit-and-find-file)) (11 . 
helm-delete-minibuffer-contents) (67108896 . helm-toggle-visible-mark) (0 . 
helm-toggle-visible-mark) (C-M-up . helm-scroll-other-window-down) (C-M-down . 
helm-scroll-other-window) (M-prior . helm-scroll-other-window-down) (M-next . 
helm-scroll-other-window) (12 . helm-recenter-top-bottom-other-window) (15 . 
helm-next-source) (10 . helm-execute-persistent-action) (9 . 
helm-select-action) (13 . helm-maybe-exit-minibuffer) (7 . helm-keyboard-quit) 
...) (action . helm-type-command-actions) (persistent-action . 
helm-M-x-persistent-action) (persistent-help . "Describe this command") 
(help-message . helm-M-x-help-message) (requires-pattern . 0) 
(filtered-candidate-transformer helm-M-x-transformer-no-sort 
helm-fuzzy-highlight-matches) (volatile) (match . identity) (redisplay . 
identity) (nomark) (coerce . helm-symbolify) (header-line . "C-j: Describe this 
command (keeping session)") (must-match) (group . helm-command) 
(match-dynamic)) ((name . "Emacs Commands") (candidates . #f(compiled-function 
() #)) (keymap keymap (keymap (13 . 
helm-confirm-and-exit-minibuffer)) keymap (21 . helm-M-x-universal-argument) 
keymap (127 . delete-backward-char) (27 keymap (13 . 

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: Displaying remote images

2020-01-24 Thread Jack Kamm
Hi Nicolas --

Thank you for reviewing my patch. I'm attaching an updated patch in
response to your review.

> I think displaying a message in this case can be annoying. It means the
> default value is not satisfying for anyone.
> ...
> I suggest to drop the `skip-warn' value altogether, and use
> `skip-silent', renamed as `skip', as the default value.
>
> It also needs a :package-version and a :safe keyword.

Done.

>> +(defun org-inline-image--buffer-unibyte ()
>> +  (string-make-unibyte (buffer-substring-no-properties
>> +(point-min) (point-max
>
> I'm surprised such a function is necessary.

I originally based that function off the way image-mode.el handles
remote files and other raw data:

https://github.com/emacs-mirror/emacs/blob/7497ee44b471f69ce59d131a6dece261e871534f/lisp/image-mode.el#L753

I re-tested whether the call to string-make-unibyte was actually
necessary, using JPG, PNG, and SVG images as test cases. I found it
wasn't necessary for cache-buffer (which visits the file in a persistent
buffer), but it was necessary for the download-always option (which uses
a temp buffer). Otherwise, the download-always option would display JPG
and PNG images as empty boxes (SVG images worked fine though).

One downside of string-make-unibyte, is that "make compile" complains
its a deprecated function. So I switched to using set-buffer-multibyte
instead, which solved the empty box issue without a deprecation warning.

>> +(defun org-inline-image--create (file width)
>
> It should be named `org--inline-image-create' or
> `org--create-inline-image'.

Done.

>> +  (let* ((remote-p (file-remote-p file))
>> + (file-or-data
>> +  (if remote-p
>
> I suggest to move the `if' within the `pcase' with an initial `guard'.

Done.

>
>> +  (pcase org-display-remote-inline-images
>> +(`download-always (with-temp-buffer (insert-file-contents file)
>> +
>> (org-inline-image--buffer-unibyte)))
>
> Wouldn't `insert-file-contents-literally' fit the bill instead?

Done, but it still required converting the temporary buffer to unibyte
as noted above.

>> +(`cache-in-buffers (let ((revert-without-query '(".*")))
>> + (with-current-buffer
>> + (find-file-noselect file)
>> +   (org-inline-image--buffer-unibyte
>
> Wouldn't the RAW argument from `find-file-noselect' prevent
> `org-inline-image--buffer-unibyte' from being used?

Unibyte conversion wasn't required here in my tests, regardless of the
RAWFILE argument, so I've removed it.

For now I've opted not to use the RAWFILE argument. My thinking is that
the user might want to view the image in its own buffer later, and if
the RAWFILE argument is set, then they'd either see the raw file, or get
a message asking to revisit the file normally.

>> +(`skip-warn (message
>> + (concat "Set `org-display-remote-inline-images'"
>> + " to display remote images."))
>
> Use continuation delimiter instead.

Fixed.

>From e0f61b9043de88161752f34d449ec173e7540202 Mon Sep 17 00:00:00 2001
From: Jack Kamm 
Date: Sun, 19 Jan 2020 14:08:01 -0800
Subject: [PATCH] org.el: Add inline remote image display

* lisp/org.el (org-display-inline-images): Add inline remote image
display. Remote image display is controlled by the new option
`org-display-remote-inline-images'.
---
 etc/ORG-NEWS |  6 ++
 lisp/org.el  | 45 -
 2 files changed, 46 insertions(+), 5 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 90e612529..e2c53d043 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -35,6 +35,12 @@ value in call to =java=.
 After editing a source block, Org will restore the window layout when
 ~org-src-window-setup~ is set to a value that modifies the layout.
 
+*** Display remote inline images
+
+Added the capability to display remote images inline.  Whether the
+images are actually displayed are controlled by the new option
+~org-display-remote-inline-images~.
+
 ** New functions
 *** ~org-columns-toggle-or-columns-quit~
 == bound to ~org-columns-toggle-or-columns-quit~ replaces the
diff --git a/lisp/org.el b/lisp/org.el
index e011ff61e..d6a591a6a 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -16739,6 +16739,45 @@ INCLUDE-LINKED is passed to `org-display-inline-images'."
 ;; For without-x builds.
 (declare-function image-refresh "image" (spec  frame))
 
+(defcustom org-display-remote-inline-images 'skip
+  "How to display remote inline images.
+Possible values of this option are:
+
+skip  Don't display remote images.
+download-always   Always download and display remote images.
+cache-buffer  Display remote images, and open them in separate buffers for
+  cacheing.  Silently update the image buffer when a file
+  change is 

Re: [ANN] org-ql 0.4 released

2020-01-24 Thread Tim Cross


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.  

What would be good is an approach based on sematic versioning similar to
npmjs.com, maven, clojars and other packaging systems. 

Semantic versioning won't solve all the issues. The lack of namespaces
or ability of libraries to depend on specific versions of a library are
both significant challenges. 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. 

Tim

Adam Porter  writes:

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

Re: [RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock

2020-01-24 Thread Nicolas Goaziou
Hello,

Dan Drake  writes:

> I asked about a way to specify a time when using org-resolve-clock instead
> of a number of minutes:
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2020-01/msg00010.html
>
> I've implemented this myself and a patch is attached. Comments welcome --
> my change works, but I'm not sure about coding style, and right now there's
> no error checking.

Thank you. Some comments follow.

> I marked the patch as a tiny change, but it does add a new menu option and
> behavior to org-resolve-clock, so there may be an argument that it's not,
> from a user perspective, a "tiny change", but code-wise it's quite simple:
> the core logic really isn't more than "ask the user for a time and
> subtract".

TINYCHANGE is only about the number of non-trivial lines of code in your
patch (15 or so).

> +(defun time-to-mins-to-keep (start-time)
> +  "Asks the user for a time and returns the number of minutes
> +from START-TIME to that time."
> +  (floor (/ (float-time
> +  (time-subtract (org-read-date t t) start-time)) 60)))

The name of the function is wrong, it should start with "org-clock".
Also, docstring's first line must contain a full sentence.

Anyway, this is used only once in your patch, I suggest to inline in
instead.
> +   (or (and (memq ch '(?k ?K))
> +(read-number "Keep how many minutes? " default))
> +   (and (memq ch '(?t ?T))
> +(time-to-mins-to-keep last-valid

See above about inlining.

Would you mind adding an ORG-NEWS entry, and, if possible, writing
a test?

Regards,

-- 
Nicolas Goaziou



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.




Re: [Question] adding document global properties drawer

2020-01-24 Thread Nicolas Goaziou
Hello,

stardiviner  writes:

> I found I can add property with name input name like "kk", "hello" etc, but
> can't add property "CATEGORY". Is there some limitation on document level
> property?

I still cannot reproduce it.

Regards,

-- 
Nicolas Goaziou



Re: [ANN] org-ql 0.4 released

2020-01-24 Thread Michael Alan Dorman
Adam Porter  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...

Mike.



org-show-notification of org-clock.el broken on MS Windows

2020-01-24 Thread Tim Schumacher
Hi folks,

I have a snippet that clocks me in, if I set the TOOD-keyword of an item to
started. So some time after working on that item on and off, I got a stack trace
and it would not change the keyword to started. The error was, that emacs was
not compiled with dbus support and I thought, hell yeah, I'm on MS Windows, I
don't have dbus here. So I looked at the stack trace and found
org-clock-notify-once-if-expired which wants to show a notification if I took
longer than I estimated. Than digging deeper I found org-show-notification which
is where the actual error happens. It checks if the function
notifications-notify exists and then tries to use it. On my system the function
is available, but does not work because I don't have dbus support.

In my opinion these two actionable items should be done:

* The function org-show-notification should be more robust. It should not fail
  if it can't fire a notification for whatever reason.
* On MS Windows the function w32-notification-notify should be used.

Maybe someone has a quick fix, if not I can try my non existant elisp foo and 
hack
together a patch tomorrow, but please be gentle with me.

Thanks for your time and great effort into org-mode!

Tim