emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: John Kitchin <jkitchin@andrew.cmu.edu>
To: Puneeth Chaganti <punchagan@gmail.com>
Cc: emacs-orgmode <emacs-orgmode@gnu.org>, Rasmus <rasmus@gmx.us>
Subject: Re: [PATCH] org-id-goto doesn't work if buffer is narrowed.
Date: Sat, 24 Oct 2015 07:33:54 -0400	[thread overview]
Message-ID: <CAJ51ETry9SEzi3C+nw3LWf=1ejUV=rh+k+eZwMeBwqjfSXaEnQ@mail.gmail.com> (raw)
In-Reply-To: <CALnw1fRk0a0SpfDASVz8G66iHH4sHGm24WnhkoW69ycBjrVnpQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2742 bytes --]

> >
> >> On Fri, Oct 23, 2015 at 8:57 PM, Rasmus <rasmus@gmx.us> wrote:
> >>> It's not obvious that org should change a—potentially—carefully
> selected
> >>> narrowed region.
> >>
> >> I agree. But, am I not explicitly asking to jump to the specified
> >> item. I don't mind the widening, at least when the call is
> >> interactive. I agree with you when some other code is calling it,
> >> though.
>

Maybe I am missing something here. I would expect org-id-goto to actually
get to the id entry when it is used independent of narrowing. When used in
a program, I would expect this behavior to be wrapped in save-restriction
type macros, so it wouldn't change your restriction. But when used
interactively, e.g. when I click on a link, I expect the point to end up on
the id entry, with the buffer open in front of me, even if that means
widening. Is there some other expectation that makes sense? I feel like it
is up to me to decide if breaking the restriction is worth visiting the
link, and only by clicking on the link or running an interactive command
makes that happen.

An alternative might be to check if a restriction is in place somehow, and
make org-id-goto not work or warn you somehow if it has to remove the
restriction.

Is it possible to save a restriction in a variable? so that something like
C-c & could restore it?  the save-restriction macro must do something like
that, but the code seems to be hidden in the C-source for me.


> >
> > I see your point, but I also remember being quite annoyed in the past
> when
> > I lost my narrow because of e.g. inserting a footnote.
>
> I see.
>
> >>> Perhaps you could mimic the way org-edit-special works for this case.
> >>
> >> You mean, display the entry in a new buffer, and any changes will be
> >> applied onto the original entry too?
> >
> > Yeah, I would prefer that.  Would that work for you or would still prefer
> > to have your buffer widened?
>
> I agree that widening a buffer that was narrowed on purpose can be
> annoying, sometimes. Most times, I think I wouldn't mind the widening.
> That said, I'm not quite sure what is the right fix for this.
>
> I find it weird to have a subtly different thing happening depending
> on whether or not the target buffer is narrowed -- entry shown in
> normal buffer when no narrowing vs. entry shown in a special/indirect
> buffer.
>
> Also, given that no other part of org really uses indirect buffers, I
> don't know if this function alone should make use of that feature.
>
> Let me know what you think.
>
> -- Puneeth
>
> PS: I've patched my org sources to do indirect buffers for this, and
> will try it out for sometime to see how it feels.
>
>

[-- Attachment #2: Type: text/html, Size: 3607 bytes --]

  reply	other threads:[~2015-10-24 11:33 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-23 15:11 [PATCH] org-id-goto doesn't work if buffer is narrowed Puneeth Chaganti
2015-10-23 15:27 ` Rasmus
2015-10-23 18:05   ` Puneeth Chaganti
2015-10-23 18:48     ` John Kitchin
2015-10-23 20:22     ` Rasmus
2015-10-24  5:29       ` Puneeth Chaganti
2015-10-24 11:33         ` John Kitchin [this message]
2015-10-24 11:49           ` Puneeth Chaganti
2015-10-24 11:57           ` Nicolas Goaziou
2015-10-24 12:47           ` Rasmus
2015-10-24 17:48             ` John Kitchin
2015-10-24 18:03               ` Rasmus
2015-10-25 11:11                 ` John Kitchin
2015-10-24 12:27         ` Rasmus
2015-10-25  2:24           ` Puneeth Chaganti
2015-10-25  3:12             ` Puneeth Chaganti
2015-10-25  8:38               ` Nicolas Goaziou
2015-10-25  9:10                 ` Puneeth Chaganti
2015-10-25  9:42                   ` Nicolas Goaziou
2015-10-25  9:57                     ` Puneeth Chaganti
2015-10-25 11:19             ` Rasmus
2015-10-26 14:14               ` Puneeth Chaganti
2015-10-23 19:59   ` Matt Lundin
2015-10-23 20:18     ` Rasmus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJ51ETry9SEzi3C+nw3LWf=1ejUV=rh+k+eZwMeBwqjfSXaEnQ@mail.gmail.com' \
    --to=jkitchin@andrew.cmu.edu \
    --cc=emacs-orgmode@gnu.org \
    --cc=punchagan@gmail.com \
    --cc=rasmus@gmx.us \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).