emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_


From: Eli Zaretskii
Subject: Re: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]
Date: Fri, 12 Jan 2024 14:32:20 +0200

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: monnier@iro.umontreal.ca, emacs-orgmode@gnu.org, 65734@debbugs.gnu.org,
>  manikulin@gmail.com, iota@whxvd.name
> Date: Fri, 12 Jan 2024 12:24:01 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Then, Org mode can instead have
> >> 
> >> (setq-local kill-line-query-function #'org-kill-line-query)
> >> (defun org-kill-line-query (beg end)
> >>   (org-with-point-at beg
> >>     (when (and (org-at-heading-p)
> >>                (progn
> >>                  (end-of-line)
> >>                  (and (< (point) end)
> >>                       (org-fold-folded-p))))
> >>        "Kill hidden subtree along with headline? ")))
> >
> > I don't know what org-with-point-at and org-fold-folded-p do, but my
> > point is that you should consider the case when kill-line kills
> > invisible text that has nothing to do with Org's headings and trees,
> > so I suggest to either make the detection code smarter (so it could
> > distinguish between the two), or make the prompt text vaguer (to not
> > claim that the text must be a subtree).
> >
> > And if that is still not clear or you disagree, let's leave it at
> > that.
> 
> I think that I see what you mean. What we can do to achieve this is
> changing `kill-line-query-function' into abnormal hook
> `kill-line-query-functions'. Then, `kill-line'/`kill-whole-line' will
> use (run-hook-with-args-until-success 'kill-line-query-functions) to
> decide whether to show a query.
> 
> Does it make sense?

It might, yes.  But do we have to _replace_ the hook? cannot we have
both?  I.e. if the new one is defined, call it, otherwise call the old
one.  That would be more backward-compatible, I think.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]