org-indent-mode documentation suggestion

2020-01-25 Thread Neil Hansen
Hello, and thank you for org-mode!

I ran into an issue yesterday when I turned on org-indent-mode and then
tried to disable org-hide-leading-stars. I ended up going on a bit of a
chase to figure out what was going on. I had just switched to a new config,
and thought that might be the problem, so I filed an issue there. It has
some more details if you'd like to take a look:

Anyways, the buffer-local variables that org-indent creates made this a
little confusing to figure out. I ended up solving it by
setting org-indent-mode-turns-in-hiding-stars to nil, but that took some
time to figure out because the documentation here suggests that I only
needed to set org-hide-leading-stars to nil:

I just wanted to suggest that the documentation be updated to mention the
buffer-local variables and how to work around org-indent's default
behavior. These two lines solved it for me, and I'm sure other star-loving
org users will want the full story on how to set this up properly:

(setq org-hide-leading-stars nil)
(setq org-indent-mode-turns-in-hiding-stars nil)

Thank you again!


Re: maintainance for the next two hours

2020-01-25 Thread Bastien
I had to clean up and remove a lot of fake accounts.

I disabled user registration on for the time being.

I will mention on Worg that users need to send an email to the gogs
admins if they want an account.

If the gogs captcha system gets better, we may re-enable registration.


Re: strange/cryptic org variables

2020-01-25 Thread Bastien

org-m was useful and the other two variables were not used outside of
`org-get-level-face', I put them in a let clause.

Thanks for pointing this issue!


Re: strange/cryptic org variables

2020-01-25 Thread Kyle Meyer
D  writes:

> org.el seems to define three weird variables: org-m, org-l and org-f
> (see below).  Two of these variables (l and f) are used exclusively in
> org-level-face, while m is not used anywhere in the code.  They don't
> appear to be used in the other source files, either.
> Is there a particular reason for them being accessible outside of the
> function?  They seem oddly.. exposed.  Or is it some kind of performance
> reason?

I doubt there's a convincing reason for these variables to exist.  They
have been around for a long time, as far back as you can trace the
history in the git repository: 4be4c5623 (version 4.12a, 2008-01-31).
Even in 4be4c5623, org-m wasn't used anywhere in the code base.

strange/cryptic org variables

2020-01-25 Thread D

org.el seems to define three weird variables: org-m, org-l and org-f
(see below).  Two of these variables (l and f) are used exclusively in
org-level-face, while m is not used anywhere in the code.  They don't
appear to be used in the other source files, either.

Is there a particular reason for them being accessible outside of the
function?  They seem oddly.. exposed.  Or is it some kind of performance

Here's the code in question, taken from Version 9.1.9, L6531 onward:

(defvar org-m nil)
(defvar org-l nil)
(defvar org-f nil)
(defun org-get-level-face (n)
  "Get the right face for match N in font-lock matching of headlines."
  (setq org-l (- (match-end 2) (match-beginning 1) 1))
  (when org-odd-levels-only (setq org-l (1+ (/ org-l 2
  (if org-cycle-level-faces
  (setq org-f (nth (% (1- org-l) org-n-level-faces) org-level-faces))
(setq org-f (nth (1- (min org-l org-n-level-faces)) org-level-faces)))
   ((eq n 1) (if org-hide-leading-stars 'org-hide org-f))
   ((eq n 2) org-f)
   (t (unless org-level-color-stars-only org-f


Re: Org-ref issues

2020-01-25 Thread John Kitchin
That function should be defined in org-ref-core.el. If it is not there,
then probably something has gone wrong in the update, or you are somehow
loading a very old version of org-ref.


Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213

On Fri, Jan 24, 2020 at 9:13 PM 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 .

RE: attachment: link type export to HTML invalid attach dir

2020-01-25 Thread Gustav Wikström
Hi again,

> -Original Message-
> From: Nicolas Goaziou 
> Sent: den 20 januari 2020 02:25
> To: Gustav Wikström 
> Cc:
> Subject: Re: attachment: link type export to HTML invalid attach dir
> Gustav Wikström  writes:
> > Ok, noted. To my defense I was thinking more in the terms of subtyping
> > then hardcoding. Because we have multiple link types which try to
> > share an interface. But the interface isn't perfect for all different
> > kinds of links.
> Then, I suggest to improve the interface.

That was kind of what I was trying to do, by allowing subtyping, so that the 
parser would be more knowledgeable about particular types of links, by allowing 
extended attributes. Maybe not implemented in the most extensible way though 
I'll admit.

My suggestion to the link parser would be to have the following properties as 
the catch-all properties for links:
- type :: Which type of link protocol applies. E.g. file, http, ftp, 
attachment, duckduckgo (ex. for a custom link abbreviation to search ddg)
- raw-path :: The path to use for the particular protocol. Would contain 
everything in the link following "protocol:"
- format :: Which format the link has. Plain, bracket or angular bracket
- description :: The description part of the link 
- begin, end, post-blank :: The default properties used for all elements. Not 
sure if contents-begin and contents-end are a part here as well.

In addition to that each protocol would be able to declare their own properties 
using a :parse function. All would probably implement a path property. Some 
would implement an options property, and some maybe would maybe declare their 
own properties.

As you've stated previously, from a performance perspective maybe it will be 
best to not expand the specific properties and instead let the expansion of 
those be handled in code by the link type owner (e.g. org-attach.el for 
attachment links). But not letting specific protocol parsers expand their own 
properties into a link makes it more difficult to implement support outside of 
emacs for the org specification, which in my opinion includes also a certain 
set of link protocols which do have their own specifications.

> > So it doesn't seem too farfetched that some of those link types would
> > benefit from additional custom properties, specific for those types.
> > =application= and =search-option= for example isn't universally
> > applicable to all link types.
> As a side note, :application is on its way out, i.e., "file+emacs" stuff
> is in "org-compat.el".
> Also, IIRC, "docview" links have "go to page" option, and they don't
> touch the parser.

Ah yes. Just briefly looking at the docview code. Docview doesn't seem to use 
the parser when extracting information about that "go to page" information from 
the link. Which means docview links doesn't really care how the link 
information is encoded in the parser anyways. Maybe if docview were allowed to 
encode custom docview information into the parsed link in the parser it and 
others could reused that encoded information later? Docview would be able to 
add a ":go-to-page" option, for example. Just a thought.

> > What I'm trying to argue for here is: Maybe it's not that crazy after
> > all to allow links to have additional properties in the parser based
> > on its type? (While certainly still trying to avoid it if possible!)
> If new link types may not function correctly without touching the
> parser, how do you create new link types out of Org's core? This is not
> modular at all.

Most link types probably won't need custom link properties anyways. But could 
maybe let the parser know stuff by use of higher order functions? Or push for 
being important enough to be included into Org and allowed to be known by the 

> > (Off topic) I'm sorry to hear that you think I'm intentionally making
> > things fuzzy.
> Not at all! My wording is terrible. When I wrote
> Also, you sometimes seem to blur, on purpose, the difference between
> "attachment" and "file" links.
> I meant something like:
>It seems to me that your intent is to have "attachment" links
>transparently become "file" links to the user.
> Hence my suggestion to use link abbreviations. There's nothing negative
> in it.

Ok, got it. Thanks for explaining. I'll admit it hasn't been totally clear to 
me what the best way forward is. After refreshing my understanding on links the 
conclusion I came to was that link abbreviations in its current form was not a 
fitting concept for attachment links. Attachments are pretty much similar to 
file links though, so even if my intention isn't to blur the meaning they will 
and should be treated very similar, since functionality is so similar.

> > One can indeed use the buffer position to derive the part of the path
> > that comes from the subtree. But leaving it at that puts more
> > requirements on the user of the 

Re: maintainance for the next two hours

2020-01-25 Thread Fraga, Eric
On Saturday, 25 Jan 2020 at 11:47, Bastien wrote:
> is now back online and usable.

Thank you!

Eric S Fraga via Emacs 28.0.50, Org release_9.3.1-94-g0ac6a9

Re: maintainance for the next two hours

2020-01-25 Thread Bastien
Bastien  writes:

> I will perform an upgrade of the gogs instance at
> during the next two hours: you won't be able to pull or push to git
> repositories. is now back online and usable.

 Bastien maintainance for the next two hours

2020-01-25 Thread Bastien
Hi all,

I will perform an upgrade of the gogs instance at
during the next two hours: you won't be able to pull or push to git

I should have sent a notice before doing so: I wanted to perform the
upgrade later on today but the server is having difficulties, so I'm
doing it right now.

I'll send an update when this is done.


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 
  (if (use-region-p)
  (funcall-interactively #'count-words-region (region-beginning) 
 (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 

(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')
  (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.