* whether in drawer? @ 2016-04-28 2:49 Samuel Wales 2016-04-28 5:38 ` Derek Feichtinger 0 siblings, 1 reply; 5+ messages in thread From: Samuel Wales @ 2016-04-28 2:49 UTC (permalink / raw) To: emacs-orgmode can one tell whether point is in a drawer? ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: whether in drawer? 2016-04-28 2:49 whether in drawer? Samuel Wales @ 2016-04-28 5:38 ` Derek Feichtinger 2016-04-28 6:00 ` Samuel Wales 0 siblings, 1 reply; 5+ messages in thread From: Derek Feichtinger @ 2016-04-28 5:38 UTC (permalink / raw) To: emacs-orgmode Hi Samuel Wales <samologist <at> gmail.com> writes: > > can one tell whether point is in a drawer? > > By coincidence just posted a patch request which contains the functionality you desire. I use org-element-at-point and then test for drawer/property drawer: (defun org-open-if-in-drawer () (let ((element (org-element-at-point))) (while (and element (not (memq (org-element-type element) '(drawer property-drawer)))) (setq element (org-element-property :parent element))) (when element (let ((pos (point))) (goto-char (org-element-property :begin element)) (org-flag-drawer nil) (goto-char pos))))) Cheers, Derek ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: whether in drawer? 2016-04-28 5:38 ` Derek Feichtinger @ 2016-04-28 6:00 ` Samuel Wales 2016-04-28 14:52 ` Adam Porter 0 siblings, 1 reply; 5+ messages in thread From: Samuel Wales @ 2016-04-28 6:00 UTC (permalink / raw) To: Derek Feichtinger; +Cc: emacs-orgmode thank you. for years i have been trying to advise undo-tree to deal with visibility properly. namely, to not try to undo or redo invisibly, but also not to leave too much stuff visible. maybe if i can get it to do canonical visibility except in drawers (where it should keep the drawer open if point is in it) it will work properly. On 4/27/16, Derek Feichtinger <dfeich@gmail.com> wrote: > Hi > > Samuel Wales <samologist <at> gmail.com> writes: > >> >> can one tell whether point is in a drawer? >> >> > By coincidence just posted a patch request which contains the functionality > you desire. I use org-element-at-point and then test for drawer/property > drawer: > > (defun org-open-if-in-drawer () > (let ((element (org-element-at-point))) > (while (and element > (not (memq (org-element-type element) > '(drawer property-drawer)))) > (setq element (org-element-property :parent element))) > (when element > (let ((pos (point))) > (goto-char (org-element-property :begin element)) > (org-flag-drawer nil) > (goto-char pos))))) > > > Cheers, > Derek > > > -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. And ANYBODY can get it. Denmark: free Karina Hansen NOW. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: whether in drawer? 2016-04-28 6:00 ` Samuel Wales @ 2016-04-28 14:52 ` Adam Porter 2016-04-28 19:43 ` Samuel Wales 0 siblings, 1 reply; 5+ messages in thread From: Adam Porter @ 2016-04-28 14:52 UTC (permalink / raw) To: emacs-orgmode Samuel Wales <samologist@gmail.com> writes: > thank you. for years i have been trying to advise undo-tree to deal > with visibility properly. namely, to not try to undo or redo > invisibly, but also not to leave too much stuff visible. maybe if i > can get it to do canonical visibility except in drawers (where it > should keep the drawer open if point is in it) it will work properly. Do you have any other posts talking about this? I'm interested in fixing this too. I've run into situations occasionally where undo-tree seems to try to operate on a region or a hidden/folded area, and it just kind of goes bonkers, and I end up having to revert the buffer. It would be nice to fix this. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: whether in drawer? 2016-04-28 14:52 ` Adam Porter @ 2016-04-28 19:43 ` Samuel Wales 0 siblings, 0 replies; 5+ messages in thread From: Samuel Wales @ 2016-04-28 19:43 UTC (permalink / raw) To: Adam Porter; +Cc: emacs-orgmode On 4/28/16, Adam Porter <adam@alphapapa.net> wrote: > Do you have any other posts talking about this? I'm interested in > fixing this too. I've run into situations occasionally where undo-tree > seems to try to operate on a region or a hidden/folded area, and it just > kind of goes bonkers, and I end up having to revert the buffer. It > would be nice to fix this. i proposed org visibility to the author of undo-tree, who did not use org at the time (but might be on this list). one suggestion i made was that undo-tree could undo and redo visibility changes as it goes about its normal operation. he thought this would require an emacs change. we cross-posted it. stefan said it wouldn't require an emacs change, but org could put visibility state information into the undo list. this is intriguing. dunno if it is feasible. === an alternative is to do what i did, kludge undo-tree with hideous, grotesque, misshapen defadvice that looks like something your cat dragged in. the following is unsightly, horror-filled code written over many years a few minutes at a time, which works for most cases. undo-tree still shows too much and confuses me after sorting, and closes drawers when undoing, and sometimes does not show the change if you do an undo and then a redo (it is supposed to because it is supposed to be asymmetric in point placement). btw, possibly outside the scope of undo-tree and org visibility, org has a few glitches where no change shows up as a change. there are also a few slightly disconcerting but pretty harmless cases where undo-boundary is set for compound operations like checkbox cookie updating. again probably in org, but maybe in undo-tree, and probably outside the scope of visibility, there are also cases, at least with logbook entries, in which you can make two separate changes to separate tasks, and cannot undo only one of them because there is no undo boundary between them. this violates the hoary old principle of "user expectation that you can undo what you did without undoing anything else". i have turned off agenda undo features, so i think it occurs with normal operation in org. perhaps logbook updating has post-command-hook fanciness that changes undo behavior? just a guess. those i did not attempt to fix. i am not capable of it. i include the following monstrous insult to programmer-kind (i am a mere user, as if /that's/ an excuse) with glorious comments for your amusement. (defadvice undo-tree-undo (after org-undo-reveal activate compile) "Make point and context visible after an undo command in org-mode." (alpha-org-reveal-for-undo)) ;; ;; ;;might be nec, perhaps because undo tree moves point to ;; ;; ;;other change (defadvice undo-tree-redo (after org-redo-reveal activate compile) "Make point and context visible after an undo command in org-mode." (alpha-org-reveal-for-undo)) (defun alpha-org-reveal-for-undo () ;; maybe we want seiza canonical if on header, else canonical (save-excursion (when (eq major-mode 'org-mode) (unless (eq last-command this-command) ;; '(undo-tree-undo ;; undo-tree-redo ;; ;; self-insert-command ;; ;; org-self-insert-command ;; ;; org-shiftmetadown ;; ;; org-shiftmetaup ;; )) (unless (or (org-at-heading-p) ;; in drawer ) (alpha-hide-parent)) ;; (org-show-entry) ;; (org-overview) ;; (recenter) ;; (if (org-at-heading-p) ;; (save-excursion ;; (forward-line 1) ;; (org-show-set-visibility 'canonical)) ;; ;; this creates ellipsis if on headline (org-show-set-visibility 'canonical) ;; (when (org-in-drawer-p) org-flag-drawer nil ;; get rid of that !@#$!@#$ ellipsis at top of window ;; fixme still need to do this after org-cycle (scroll-lock-previous-line) (scroll-lock-next-line) )) (when (org-truely-invisible-p) (org-show-set-visibility 'canonical)) ;; notwork ;; (save-excursion ;; (move-to-window-line 1) ;; (redisplay)) )) ;; (when (org-at-heading-p) ;; ;; (when (outline-invisible-p) ;; '(org-reveal t) ;; (org-show-set-visibility 'canonical)) ;; ;; (when (eq last-command 'alpha-org-sort-siblings) ;; (alpha-org-show-children-and-entry)))) ;;(ad-unadvise 'undo) ;; elsewhere (setq org-self-insert-cluster-for-undo nil) ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-04-28 19:43 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-04-28 2:49 whether in drawer? Samuel Wales 2016-04-28 5:38 ` Derek Feichtinger 2016-04-28 6:00 ` Samuel Wales 2016-04-28 14:52 ` Adam Porter 2016-04-28 19:43 ` Samuel Wales
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).