unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: hugo@heagren.com
To: 58071@debbugs.gnu.org
Subject: bug#58071: 28.2; [PATCH] jumprel: A tool to find/create related files
Date: Fri, 28 Oct 2022 23:08:26 +0100	[thread overview]
Message-ID: <4134dcab7071de01a2a737a22fd06e33@heagren.com> (raw)
In-Reply-To: <878rm7wvib.fsf@cassou.me>

Hi Damien,

I've been looking for a package just like this for a while now. I was
close to getting round to writing one, but now you have, so thank you!

I've had a look through it, and so far I really like it. I think its
probably a pretty common problem for lots of Emacs users (jumping to
related files easily), so I think including it in the core would make
sense, but I can also see the points others have made and wouldn't
mind downloading from somewhere else either.

Some comments:
- The package doesn't work for non-file based buffers, which in
   particular means it doesn't work in org (roam) capture buffers (for
   jumping to the pdf I'm making notes on). I appreciate that you need
   some sort of reference to get off the ground, and that /normally/
   that will be a file name, but for my use case it would be great to
   be able to use other things as well (org roam node id, or a citation
   ref). This would make a big difference to me. Of course, the package
   doesn't have to do all the work of handling these different cases,
   so long as the user can write their own functions for everything
   (and it is well documented how these interact/what types of inputs
   and outputs everything needs).
- Conversely, the package hard-codes /how/ to jump to a file---with
   `find-file'. This means I can't go the other way, from a pdf file to
   an org-roam-capture buffer on its notes (which is what I would like
   to do). Another way of saying this is the package assumes all places
   will be files, and that the best way to get to them is `find-file'.
   It would be nice to be able to specify (perhaps customisable,
   arbitrary?) types of places and functions actually used to /do/ the
   jumping. (though I agree that `find-file' is a very sensible
   default).
- At the moment, the presented list of places (files) to jump to is
   just a list of strings (as in, there is no file metadata, so things
   like Marginalia don't work properly). I think this should be fixed.
   This might also make it easier to implement different kinds of
   jumpers; have an alist of ~(CATEGORY . JUMP-FUNCTION)~ function
   pairs. Whenever the user selects something from the jump list, get
   its category, look that up, and then ~(funcall JUMP-FUNCTION
   SELECTION)~. Ideally, any such system should also support
   pretty-printing functions for non-string (e.g. org-roam nodes)
   places. Just a thought, I don't know how easy this would be to
   implement.
- Documentation could be improved, but you knew that already, and
   there isn't much point until the package reaches a more stable
   state. Once it is, I would be happy to write some if you want help.
- I can see myself using something like `:filler' a lot, but not
   necessarily for altering the buffer, and which runs every time I
   jump (or maybe every time I jump, /and/ the buffer I end up is newly
   created---even if the file already existed). I'm thinking about
   things like setting local variables which I might use later for
   establishing targets to jump /back/ to from that buffer. Perhaps
   something like this could be included in a a separate `:hook' or
   `:final' keyword, which would be run /last/ in the jumping process.

Hope some of that is useful, or finds its way into some code. I'd be
happy to make patch contributions, but at this stage I'd like to hear
what you think about how I want to use the package and what you want
to include before I start hacking.

Hugo





      parent reply	other threads:[~2022-10-28 22:08 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-25 11:20 bug#58071: 28.2; [PATCH] jumprel: A tool to find/create related files Damien Cassou
2022-09-26  7:42 ` Eli Zaretskii
2022-09-28 19:26   ` Damien Cassou
2022-09-29  8:54     ` Eli Zaretskii
2022-09-30  8:43       ` Damien Cassou
2022-09-30 10:38         ` Eli Zaretskii
2022-09-29 10:46     ` Lars Ingebrigtsen
2022-09-30  8:44       ` Damien Cassou
2022-10-06  6:09   ` Damien Cassou
2022-09-26 11:05 ` Lars Ingebrigtsen
2022-09-26 13:37   ` Stefan Kangas
2022-09-27 11:34     ` Lars Ingebrigtsen
2022-10-28 22:08 ` hugo [this message]

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.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=4134dcab7071de01a2a737a22fd06e33@heagren.com \
    --to=hugo@heagren.com \
    --cc=58071@debbugs.gnu.org \
    /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.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).