org-indent-mode documentation suggestion
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: https://github.com/MatthewZMD/.emacs.d/issues/28 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: https://orgmode.org/manual/Clean-view.html 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! Neil
Re: code.orgmode.org maintainance for the next two hours
I had to clean up code.orgmode.org and remove a lot of fake accounts. I disabled user registration on code.orgmode.org 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. -- Bastien
Re: strange/cryptic org variables
Hi, 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! -- Bastien
Re: strange/cryptic org variables
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
Hello, 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? 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))) (cond ((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 Cheers, DW
Re: Org-ref issues
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.
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
On Fri, Jan 24, 2020 at 9:13 PM Marvin M. Doyley
wrote:
> 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
Hi again, > -Original Message- > From: Nicolas Goaziou > Sent: den 20 januari 2020 02:25 > To: Gustav Wikström > Cc: emacs-orgmode@gnu.org > 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 ([[protocol:path][description]]) - 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 parser. > > (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: code.orgmode.org maintainance for the next two hours
On Saturday, 25 Jan 2020 at 11:47, Bastien wrote: > code.orgmode.org is now back online and usable. Thank you! -- Eric S Fraga via Emacs 28.0.50, Org release_9.3.1-94-g0ac6a9
Re: code.orgmode.org maintainance for the next two hours
Bastien writes: > I will perform an upgrade of the gogs instance at code.orgmode.org > during the next two hours: you won't be able to pull or push to git > repositories. code.orgmode.org is now back online and usable. -- Bastien
code.orgmode.org maintainance for the next two hours
Hi all, I will perform an upgrade of the gogs instance at code.orgmode.org during the next two hours: you won't be able to pull or push to git repositories. 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. -- Bastien
Re: org-word-count exemptions
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
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.
