Bug: Weird error message whenever creating org file [8.2.5h (8.2.5h-elpa @ /Users/kevin/.emacs.d/elpa/org-20140130/)]
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
http://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org-mode mailing list.
Whenever I create a new *.org file, I get this error message:
File mode specification error: (error "'recenter'ing a window that does
not display current-buffer.")
Emacs : GNU Emacs 26.3 (build 1, x86_64-apple-darwin18.2.0, NS appkit-1671.20
Version 10.14.3 (Build 18D109))
of 2019-09-02
Package: Org-mode version 8.2.5h (8.2.5h-elpa @
/Users/kevin/.emacs.d/elpa/org-20140130/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-after-todo-state-change-hook '(org-clock-out-if-current)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-agenda-files '("~/org/")
org-mode-hook '(#[nil "\300\301\302\303\304$\207"
[org-add-hook change-major-mode-hook org-show-block-all
append local]
5]
#[nil "\300\301\302\303\304$\207"
[org-add-hook change-major-mode-hook
org-babel-show-result-all append local]
5]
org-babel-result-hide-spec org-babel-hide-all-hashes
turn-on-visual-line-mode)
org-confirm-elisp-link-function 'yes-or-no-p
org-startup-indented t
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-hide-block-toggle-maybe
org-src-native-tab-command-maybe
org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-log-done 'time
org-occur-hook '(org-first-headline-recenter)
org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point
org-babel-execute-safely-maybe)
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-hide-inline-tasks org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-todo-keywords '((sequence "TODO" "WAITING" "DONE"))
org-speed-command-hook '(org-speed-command-default-hook
org-babel-speed-command-hook)
org-confirm-shell-link-function 'yes-or-no-p
)
[SOLUTION] Re: [PATCH] Show hidden drawers when org-cycle on headlines
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 stardiviner writes: > I think the hidden drawers info is useful for users, this should be > shown when org-cycle on headlines. > > Here is the patch. I found another solution: Add file-local variable to eval to the Contacts.org file: #+begin_src org # Local Variables: # eval: (let ((current-prefix-arg '(64))) (call-interactively 'org-cycle)) # End: #+end_src This is just a workaround. Not very close to my requirement which expand drawers when press Tab on a single headline. Because this situation only need in org-contacts or similar things. So I use file-local variables to do it. Maybe I can define buffer local keybindings to do it better. - -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 -BEGIN PGP SIGNATURE- iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl6WYtQUHG51bWJjaGls ZEBnbWFpbC5jb20ACgkQG13xyVromsPN1Qf+KK2RBmwTrFrvmb16EMEWlUQ3MyRG jwNu59lfvWHYe9tp3a8UeXvAht5pFfSNF5CNsf4ueh1FSyUd5RSsF/L7QFovqMVb wAmT+mYEP/OacKPxfRHdIWjUz7ZlsFj34vK8362D3PQcsXheNCjiMPnzOte86xH/ ZRhcd5+U4gk+0ySa1tj/CBBTWfBgn2tNTVrBoqPlBuG6aWOnMlor+v4rx5nLgfaa ZOOnhqS4M223rzMKL5V4M+UcY/+lD9giGYr8g97degbrJqVpRD7FYJ2T5A1atbDc WCE3dA7i0rxBhit/r2ytvPEMj7Kp/VJla+VddvEvCf2xrIAYye0Uj8hfqw== =wGia -END PGP SIGNATURE-
Re: [SOLVED] Re: [PATCH] Show hidden drawers when org-cycle on headlines
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nicolas Goaziou writes: > Hello, > > stardiviner writes: > >> I agree. As I described in my given example "org-contacts", which include >> person >> info in properties drawer. That's why I want to expand when I press "Tab" on >> expanding headline. If I see a contact's info with "C-u C-u C-u Tab" is not >> convenient. > > You can rebind it. > >> Is it possible to change "org-cycle-hide-drawers" to >> "org-cycle-toggle-drawers". >> Make it more extendable. Because that function only changed one argument of >> "org-flag-drawer". If so some user like me will be easy to toggle hide/show >> drawers. (Of course, I don't want to add redundant code in my Emacs init.) If >> this is fine, I will re-edit my patch. Remove defcustom option, and hook on >> cycle. Only keep changes in "org-cycle-hide-drawers". > > I think something is wrong with `org-cycle-hide-drawers' at the moment. > This function was initially meant to be added to `org-cycle-hook' to > re-hide drawers. It should only re-hide properties drawers. In any case, > it is not needed to expand this function, it should be trimmed down to > only take care of property drawers. > > What is needed, though, it a tooling similar to block visibility > functions, i.e., `org-hide-block-toggle', `org-hide-block-hall', and, > maybe, `org-hide-block-toggle-maybe'. Regular drawers should get the > same treatment as blocks. > > If you look at `org-cycle' code, there is a comment > > ;; Drawers: delegate to `org-flag-drawer'. > > This part should be extracted into a new function. This sounds reasonable. (I deleted my patch on my local fork, I think your solution is better.) - -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 -BEGIN PGP SIGNATURE- iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl6WX64UHG51bWJjaGls ZEBnbWFpbC5jb20ACgkQG13xyVromsMKJggAzKm3lD0NTcG4eak7khuzw5bbt9W6 MNi8kkK61LWaPfW+BgCGxJz+RAYnKnPca7JDZ15xEwcVc1/UIFZ4bFTmeH25/yjp 49KsTVR4E8mgueAgm+Js1uNTj2GUXhvBpiu8RjPe6578GHzopLUbBgvTgPtZVswa A9Mr3ecu3lFMja3KfjoB73w3sa6UncwQ3zqhiV6zqVFAcrO02YYfgLAFhmYjKQ5h b5hkdxliZsL6H6kgLG7TQFwu1S1vpgGZNaZvz6sS9h3PO3UwglbCGxWo8EFsYHiz +YFJMw3FcGxdXygp9l+ypG1Zhpwr7arZE8Zuq4ypduxmjWkUyOG7O6dbdA== =haRH -END PGP SIGNATURE-
Re: org-ref: xxx-add-bibtex-entry with an org-capture like interface
That function inserts into a bibtex file, and if you don't save it then the new entry is not "findable", so it is somewhat critical to do that in my mind. It could make sense to check if there is a file attached to the buffer though, and only save in that case. That would preserve the current behavior, and solve your problem I think. WDYT? Daniele Nicolodi writes: > On 09-04-2020 13:43, John Kitchin wrote: >> This is basically what doi-add-bibtex-entry does. There isn't one >> function that does arxiv too, but there is arxiv-add-bibtex-entry. Those >> are both commands in org-ref. These don't pop up a buffer for approval, >> that is something you would have to build yourself. >> >> There are many workflows people want, the one above works for me when I >> am writing, and just want to add entries with minimal disruption. I >> usually polish the entries later if needed. I can see a slower, approach >> like you describe too. > > Hello John, > > I have been able to hack something combining org-capture and the utility > functions you mention that implements the workflow I described. > > There is only one issue: doi-utils-insert-bibtex-entry-from-doi contains > a (save-buffer) call that does not play nicely when I call it on a > temporary buffer. Why is the (save-buffer) there? > doi-utils-insert-bibtex-entry-from-doi looks like an utility function, > thus I think it should not try to save the current buffer. What do you > think? > > Thank you. > > Cheers, > Dan -- 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
Re: Assistant to remove unused IDs of org-id
Hi Adam, thanx for your feedback ! Your main point (the central function beeing to long) is undisputed; will fix this during the next refactoring ... Best regards, Marc Am 13.04.2020 um 22:04 schrieb 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: Assistant to remove unused IDs of org-id
Hi Ihor, Thanx ! Fixed it. Details: I am now checking (string= (org-attach-dir-from-id id) (org--attach-dir)) to see if the ID is used in the attachment dir (if it exists). Background: I do not use attachments myself; did not remember, they use IDs :-/ Best regards, Marc Am 14.04.2020 um 05:02 schrieb Ihor Radchenko: I quickly looked through the code. It seems that you do not consider attachments, which are normally stored in a folder named after the entry's ID property. Deleting those ID is terrible idea. Best, Ihor Marc-Oliver Ihm writes: Hi, 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). Best regards Marc
Solved inline image problem from 2015
Aloha all, Five (!) years ago, I came to the list with a problem toggling inline image display. No matter what I did, images were displayed in the buffer. Despite some good help from Rasmus, I wasn't able to solve the problem at that time. A few years ago, I noticed the problem is restricted to png files, which I was exporting from R. For a long while I solved the problem by not exporting png files :) Recently, I needed png files again and ran into my old problem. Toggling inline images had no effect on the png files, which were always displayed in the buffer. It appears the problem has to do with interlacing in the png file. I used ImageMagick to get rid of the interlacing --- mogrify -interlace none *.png. Fixed! All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
Re: org-ref: xxx-add-bibtex-entry with an org-capture like interface
On 09-04-2020 13:43, John Kitchin wrote: > This is basically what doi-add-bibtex-entry does. There isn't one > function that does arxiv too, but there is arxiv-add-bibtex-entry. Those > are both commands in org-ref. These don't pop up a buffer for approval, > that is something you would have to build yourself. > > There are many workflows people want, the one above works for me when I > am writing, and just want to add entries with minimal disruption. I > usually polish the entries later if needed. I can see a slower, approach > like you describe too. Hello John, I have been able to hack something combining org-capture and the utility functions you mention that implements the workflow I described. There is only one issue: doi-utils-insert-bibtex-entry-from-doi contains a (save-buffer) call that does not play nicely when I call it on a temporary buffer. Why is the (save-buffer) there? doi-utils-insert-bibtex-entry-from-doi looks like an utility function, thus I think it should not try to save the current buffer. What do you think? Thank you. Cheers, Dan
Re: [SOLVED] Re: [PATCH] Show hidden drawers when org-cycle on headlines
> It makes sense if point is on the drawer, and Org does this already. > > If point is on a headline, possibly a zillion lines above, it doesn't, > at least not as a common operation. Well. It's hard to judge for me if my use case is common or not. Since there are no many other replies in the thread, I have to agree that it is indeed uncommon. Nicolas Goaziou writes: > Hello, > > Ihor Radchenko writes: > >> In some of my entries, I have long tables storing historical data. >> These tables tend to be extremely long and I sometimes hide them inside >> a drawer. Opening these drawers (or a customised list of drawers) on >> would actually make sense for me. > > It makes sense if point is on the drawer, and Org does this already. > > If point is on a headline, possibly a zillion lines above, it doesn't, > at least not as a common operation. > > Regards, > > -- > Nicolas Goaziou -- Ihor Radchenko, PhD, Center for Advancing Materials Performance from the Nanoscale (CAMP-nano) State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg
Re: [SOLVED] Re: [PATCH] Show hidden drawers when org-cycle on headlines
Hello, Ihor Radchenko writes: > In some of my entries, I have long tables storing historical data. > These tables tend to be extremely long and I sometimes hide them inside > a drawer. Opening these drawers (or a customised list of drawers) on > would actually make sense for me. It makes sense if point is on the drawer, and Org does this already. If point is on a headline, possibly a zillion lines above, it doesn't, at least not as a common operation. Regards, -- Nicolas Goaziou
Re: [SOLVED] Re: [PATCH] Show hidden drawers when org-cycle on headlines
Hello, stardiviner writes: > I agree. As I described in my given example "org-contacts", which include > person > info in properties drawer. That's why I want to expand when I press "Tab" on > expanding headline. If I see a contact's info with "C-u C-u C-u Tab" is not > convenient. You can rebind it. > Is it possible to change "org-cycle-hide-drawers" to > "org-cycle-toggle-drawers". > Make it more extendable. Because that function only changed one argument of > "org-flag-drawer". If so some user like me will be easy to toggle hide/show > drawers. (Of course, I don't want to add redundant code in my Emacs init.) If > this is fine, I will re-edit my patch. Remove defcustom option, and hook on > cycle. Only keep changes in "org-cycle-hide-drawers". I think something is wrong with `org-cycle-hide-drawers' at the moment. This function was initially meant to be added to `org-cycle-hook' to re-hide drawers. It should only re-hide properties drawers. In any case, it is not needed to expand this function, it should be trimmed down to only take care of property drawers. What is needed, though, it a tooling similar to block visibility functions, i.e., `org-hide-block-toggle', `org-hide-block-hall', and, maybe, `org-hide-block-toggle-maybe'. Regular drawers should get the same treatment as blocks. If you look at `org-cycle' code, there is a comment ;; Drawers: delegate to `org-flag-drawer'. This part should be extracted into a new function. Regards, -- Nicolas Goaziou
