* 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).