Feature Requests (minor)

[tefkah]

Please post your major feature requests down below. With minor we mean requests such as "I want to be able to filter out certain nodes" or "I want to have different colors".
We make no promises about how or when we will get to these request, but we will certainly take them into consideration.

EDIT: Since I'd classify all except for Jethro's request as minor, this discussion has been renamed.

[jethrokuan]

One thing I'd like to see is org-roam-ui double as a publishing platform. This shouldn't be too different from what it is currently supported now, with a few differences:

• Instead of having the backend serve up the nodes and edges, export them into a json file as part of the website's assets
• Instead of having the backend serve the Org files, use Orgajs to generate the required HTML

[kirillrogovoy]

I also thought about that. I think it's more complex than it seems on the surface (if done well), but still doable.

An alternative implementation would be to serve the pages "on-demand" instead of statically building them (SSR not SSG). There are pros and cons, but one thing I don't want is forgetting to build the fresh build once in a while.

Both ways are easily done with Nextjs out of the box.

[MeetThePatel]

This feature would be absolutely amazing.

I'm in the process of making a perosnal website with a "braindump" and my initial thought to include org-roam-server (or now, org-roam-ui) was to have the org-roam-ui server running on the web server and expose the port to the public as a path on my website, but @jethrokuan 's idea seem much better.

[jgru]

Hi @kirillrogovoy,
has there been any progress on this feature?
Maybe even just a workaround?

[mmance]

I too am interested in having the HTML public facing to share my brain dump.

[tecosaur]

Heyo 👋 this looks great!

I was pretty happy to see in the wishlist:

Colorization options (by neighbors, centrality, etc)

On this point I'm curious if you might have seen https://org-roam.discourse.group/t/application-of-graph-theory-to-roam-link-network ?

[tecosaur]

Great! I'm afraid I missed your response on Reddit if you made one, but it's nice to hear you're interested in this sort of thing 🙂.

[tefkah]

I've been finally working on this. This is coloring by communities found using the Louvain algorithm.

I've also been playing around with Pagerank but I don't really have a good idea how to visualize it: color the first X (10?) highest value notes a different color? Dividing up these values is the bigger issue, any good ideas?

[blester125]

There used to be a browser extension that showed the page rank of a website and it was always a number between 1 and 10. Whatever that normalization was could be used, then color each number differently.

Or sort nodes by page rank and then color top X% one color, next X% a different one, etc.

[tefkah]

I implemented the community coloring right now and will do the rest later.

The problem with the pagerank and other measures I tried (eccentricity, betweenness centrality) was that the variance between nodes was HUGE! Like, 6/700 nodes in the top 50% and the rest in the bottom. This is okay, but doesn't really lead to super useful coloring strategies, as a uniform percentage cutoff would leave you with roughly 14 nodes colored and the rest all the same. There might be a better coarse-graining strategy here than a uniform one (maybe logarithmic) but wasn't too satisfied with it.

The most useful thing to do I figured it to offer two colors and a slider for setting a cutoff. This way you can at a glance see which nodes are doing the heavy lifting/are of interest. You would then use it most of the time with a more minimal two tone colors scheme (which is reasonable), or would use it very occassionally to get some insight into your graph. The problem I have with this is that the latter seems more like a "tool" rather than a general coloring strategy and should probably be sectioned like that, along with some other tools (such as "find a/the shortest path between nodes A and B"). I don't know how I want to implement that yet however, so I will postpone this.

[tecosaur]

I'm thinking that most of these graph theory based concepts would be most useful as a set of tools to graphically analyse ones graph network -- which as you say, would probably make the most sense in a dedicated section.

[alvorithm]

I would like to have the ability to filter links (i.e. only links tagged in a particular way) and have arrows indicating direction (excuse me if this is possible already).

[tefkah]

Tag filters are coming, and arrows are not there yet, but should be easy to add, give me a second. In the meantime, there is the "directional particles" option, which sends particles down the links in the direction of said link. This is kinda slow though.

[tefkah]

Et voila, latest build should have arrows

[alvorithm]

From the following discussion I get that the tag filter is on tagged nodes, but not on tagged links; is that right?

For the avoidance of confusion, the feature I was wishing for here was to selectively display / style links of specific types. This would allow one to display in a different color (e.g.) links to examples, as [[example:holofun][holomorphic function]] (using this: https://orgmode.org/manual/Adding-Hyperlink-Types.html).

Would that be possible?

[tefkah]

It is indeed not working for links. Are those links even picked up by org-roam? If not, we have no way of adding them. And generally such generic coloring/filtering features will be someways off, for now they are all added by hand until we have a better system!
Although it would certainly be possible, I just don't know how many people will use such a thing (although it sounds similar to #24)

[thriveth]

Color by tag would be a great addition for me.

One thing I really like about Obsidian is that making a wiki link creates a graph node even if the note itself doesn't exist. These placeholder notes are great as reminders of stuff I want to expand on later.

In org-roam, I emulate this by using a "stub" tag for empty placeholder notes. It would be really useful to be able to show these in a different color.

[rberaldo]

This is a feature I'd really appreciate too. I migrated from Obsidian and have lots of notes with [[roam:]] links leading to nodes that haven't been created yet. A visualization in the UI would be a great way of parsing which nodes I would like to work on first.

[tefkah]

This is included in the latest build!

[tefkah]

Unfortunately there is no way for us to know what the title of such a node was, nor do [roam:] links get picked up by org-roam. If you change them to ids, they will be picked up now, but depending on what comes after roam: it might be rather difficult to parse

[egrefen]

I really like the ability to open a local graph by clicking on a node, and then clock on other nodes to "grow" the local graph. However, it would be good to have some (optional?) visualisation of what nodes are unexpanded, and perhaps also of how many nodes would appear if that node were to be expanded?

[tefkah]

I like that idea, but I am not sure how to implement that, any suggestions? At the moment this is sort of done with the color/size of the nodes, you can (sort of) implement your own color scheme. By default, nodes with one connection is grey, two is yellow, three green etc. For me this is useful enough to decide which node can be expanded, but if you know a better way we'll see what we can do!

[tecosaur]

My 2c, unexpandable = grey works :)

[egrefen]

I note from one comment above that this is coming soon, but the main thing missing for me from org-roam-server is the ability to filter by tag.

[tefkah]

It's coming very soon! Working on it at the moment

[egrefen]

👍

[egrefen]

I would love it if I could open a local graph for a node whereby locality if defined by a number N of hops, e.g. open all nodes within distance N=2 of the target node (in the current implementation, locality is based on N=1). For my personal use case, I doubt I would need N greater than 2, but it would be nice to have the option.

[tefkah]

This is on the planned features list!

[tefkah]

This has been added!

[egrefen]

Could we not have a context menu pop up when we right click a node giving the possible actions on it (e.g. zoom on node, get local graph, open buffer in emacs, etc)? It would be great for discovery as you add features and functionality.

[tefkah]

Im adding it at the moment, great suggestion

[tefkah]

This is now in the latest build!

[blester125]

I was thinking deeper about how to handle cite links and nodes, there are a few design questions (balanced with the complexity of implementation, avoiding too many if x == cite special cases, and UI design).

Right now, if you have a cite link with some ref and there is a node with that value for their :ROAM_REFS: property, then you get a special cite link (which can be customized separately from a normal node, which I love). However, if you have a cite link that whose ref doesn't have a corresponding node—for example, you are citing a paper, but you don't have specific notes on that paper itself—the cite link does not appear. I think this is a weakness in the UI, often citations to the same work suggest connections between two clusters. This connection is not currently visible in the graph.

I'm not an expert in TS so I can't even really find where this like graph creation in the UI happen, but based on the data set from the elisp code, it seems like nodes are created based on the node list, and then links are created based on the link list. Right now, cite links that have a node with the correct :ROAM_REFS: gets turned into an (id, id, "cite") tuple in elisp, while cite links that don't reference a specific node are (id ref "cite") tuples. I seems like links that have ids in their dest are rendered and the "cite" type is used for styling.

I would propose that in addition to building all the nodes in the node list, we also build nodes for every ref in the collection of cite links. This will add nodes that are just citations (without notes) to the graph, then when building links, cite links for the form (id, ref "cite") can be rendered, connecting the real node to the new ref-only node. This would allow you to see connections that are based only on citations, without having to require a note/node for that specific citation key.

This creates a few UI questions:

1. Should a ref only citation node be styled different than a ref node with an attached note (and how does this effect the complexity of styling code)? Should they just be different options (colors, etc.) or should their just be something like an offset or some sort of note symbol that is included when there is a note?
2. How are cite links styled when they link to a ref only node vs a ref node with an associated node?
3. How to detect the difference between links to a ref only vs an id node for a cite link? Do you have a different link type (would be an easy change in the org-roam-ui--send-graphdata function)? Do you look at the value (does it look like an ID?)? Or do you create ref only nodes with a special property so you know they are ref only and use that when rending the link the points to them.
4. How do you handle when a user clicks on a ref only node expecting it to open in emacs? Trigger the capture system in emacs? Do nothing? Pop a warning?

Sorry for the wall of text but if anyone that thoughts on the UI (and pointers to where I would start hacking on this idea in the TS code) I could probably help try out a few ideas.

[tefkah]

Great suggestion! I hadn't even thought about tracking non-node refs, didn't even know org-roam kept track of those, but that makes sense now that I think about it.

AFAIK these nodes do not exist in the node table, correct? It would not be too difficult to simply add these to the nodes with a fake id, just like the normal cite-nodes have, and then give them a different link type, say "ref" instead of cite, or just keep track of them as not having the "ROAM_REFS" property. Ideally we'd do both, as otherwise we would be checking the nodes for links for nodes, which is not very efficient.

As to how this would be done UI wise: I'd probably leave that up to the user and provide separate options for these guys, under a toggle called "Show citations without a note" or something like that. The Tweaks menu needs some reorganizing anyway, and this is a good excuse (the "Visual" panel is getting a bit too unwieldy).

If you are interested in contributing to the typescript side as well, it would probably be quickest to have an onboarding call with one of us, as getting through that alone is not very easy. If you don't feel like that however, you should mostly look at

1. The updateGraphData function
2. The filteredNodes/Links and scopedNode/Links variables
3. The getLinkColor and getNodeColor functions (I apologize in advance for these)
4. The nodeColor, linkColor, linkWidth etc props of the graphs
   This is all in index.tsx

For the customization, have a look at tweaks.tsx, specifically things having to do with nodeColorScheme etc.

[tefkah]

We now have tag filtering and coloring! It's still slightly buggy (the filtering mainly, the first filter does not seem to be picked up nicely) but the rest works quite well! Let me know what you think and if it works (conceptually) like how you would expect!

From now on I will post these kinds of "changelogs" here: #30

[egrefen]

In org-roam-server I could specify which tags should be filtered out when I open the graph. This is useful, because I typically don't want to see the nodes for my dailies (tagged journal) unless I explicitly remove the filter. Any chance we can have a variable control default filters here too?

[tefkah]

Hmmm the filters you set will be remembered when you refresh, is that not enough? To be fair: it did not show you it did this, because I forgot to set that, but it do it!
The current build shows them correctly on refresh (and makes selecting them not as buggy haha)

[tefkah]

Would it be easy to use +tag and -tag searches?

If you were referring to whitelisting, this has now been added.

[tefkah]

If you were referring to actually looking for notes, then maybe! Seems like a cool feature, a more realtime filtering for your notes than a static filter like currently.

[tecosaur]

I was indeed referring to easy white/black listing of tags 🙂 you've been fantastically responsive!

[rberaldo]

Flexible coloring. For instance, although I don't tag my literature review notes, they always have an @ in the title. I'd like to be able to set a color to all notes that have a line like #\+title\:.*@.* or some other regexp.

[tefkah]

Such generic coloring features will be someways off I'm afraid, together with generic filtering. We would love to add something like this, but this would either involve adding such a filter for every usecase, which I'd like to avoid, or creating a very generic way to display tags, like a more user-friendly query language for org-roam like org-ql. The latter would be great, and I know @kirillrogovoy is very interested in creating something like that, but it will be someways off. Until then, we will focus on the bigger usecases such as filtering by tags, sorry!

[rberaldo]

No need to be sorry! org-roam-ui is already making me very happy as it is. I transferred my notes over from Obsidian and wanted to go over them. The graph has been invaluable to make that work!

[Zik42]

No one says about keyboard driven usage. Would to have at least some interface to navigate in graph using emacs and applying some settings to view, etc. Or keyboard hotkeys inside web-app ( but emacs is better...) . Or atleast some cli to control it.

[tefkah]

I think this is valuable. At the moment there are only two commands, orui-node-zoom and orui-node-local, to zoom and open nodes respectively.

What specific things would you want to be able to control from Emacs?

[Nan0Scho1ar]

Commands to control zoom in/out would be a nice feature. The existing orui commands work well to center the selected node but if you try and render the graph inside emacs using xwidgets webkit after a few hops the graph gets super zoomed out and there isn't really a good way to zoom it back in due to the mouse scrolling limitations of this setup. Would also people to set up bindings to zoom in and out a bit without shifting focus from the editing buffer regardless of what is used to display it.

[Enhancifire]

Is there a way to open the page in a specific browser? If there isn't, can you provide a way to do so through interfacing with the shell?

[thriveth]

See this: #8 (comment)

[serycjon]

It would be nice to show node labels "more intelligently". Now we can have all labels shown or no labels shown, based on the "label appearance scale". It would be really cool, if it worked something like maps, where you see only the most important labels when zoomed out (big cities) and as you zoom in, more labels (villages, street names, ...) start appearing.
This could be done based on number of in/outcoming links, or perhaps user-specifiable node-importance function.

[tefkah]

Wait that should actually work as intended, so I'm not sure what went wrong on your end.

[tefkah]

Ah great! I have sometimes also had that issue, I don't think you can "hot-reload" the graph very well, maybe that was what happened?

[thriveth]

...The info hover text seems to be the same on the two new sliders, though? But the effect seems to work and I agree it is hard to figure out exactly how to set the parameters but it'll work with a bit of trial and error!

[thriveth]

I did not hot reload the graph as such, I turned off ORUI and the browser before pulling the new update, then restarted and there it was. But again, after hitting Reload it worked fine again, don't know what happened there.

[tefkah]

Oh whoops yes the text is the same, that should not be the case, thanks for pointing it out!

[tefkah]

More ways to manipulate nodes from the UI. Currently it's only possible to create nodes or to delete file nodes. Would be great if we could

Delete all kinds of nodes

I'm not sure what kind of behavior would be best here.
If you have a hierarchy like this

* Note :with-id
  ** Rando heading
  ** 'Nother

Should deleting * Note :with-id cause all the subnodes to be deleted as well? Probably. But what if you have it like this

* Note :with-id
  ** Rando heading
  ** 'Nother :also-has id

Then it should probably not delete it's subnodes right? But then you have some weird floating notes that will attach itself to another node, that's also not ideal.

The best way is probably to have it delete all the subnodes as well, don't really see the other use case

Set all kinds of properties

Should not be too hard to be able to set Priority, Todo, etc statuses from the ui, and sounds mildly useful.

Interface with other Tools

For my own use I'm mostly thinking about Zotero here. I haven't really looked at Zotero's API in depth, but should be doable. I'd love to be able to

• Open items/pdfs from orui
• Open items/pdfs in orui?
• See all your (or a subsection of your) Zotero items in the orui graph, just like we have non existent citations now. This could be fantastic, but only if we are able to find a way to filter this efficiently and in a more "dwim" style than "here's all your fucking files, figure it out"
• A man can dream, and this would involve some zotero developments/integration with the Wikicite plugin, but: plot citation links in ORUI! Who needs connectedpapers.com when you've got ORUI babyy. Probably too hard, but fun to think about.

Just opening things would be cool to start.

[wztdream]

I noticed there is a "Open in Zotero" item when you right click a node in orui, but there is no action when click it. I did some homework and figured out zotero allows open PDFviewer(build in in zotero) from terminal, so it should be easy to do it orui too. All we need is provide the pdf file path.

Here is the code that maybe useful for this feature, or you can make it customizable and allow user to define there own function to open in zotero?

     (defun my-zotero-open-pdf (fpath)
       ;; parse file name to ITEM ID
       (let ((id (substring fpath 55 63)))
         (start-process-shell-command "zotero open pdf" nil (format "setsid -w xdg-open zotero://open-pdf/library/items/%s" id)) ; setsid -w to prevent xdg-open kill child process
         )
       )

[thriveth]

When expanding nodes in local view, the already open nodes should stay fixed in their location like in.. Ehm, that Wikipedia expandable graph view that was linked somewhere in the early discussions of org-roam-ui.

In order to be really useful, I as a use should only have to orient myself once in the graphical layout of the parts if the graph that I have already expanded, and the only change should be in the new nodes that open when I click a node to expand it.
As it is now, the local graph gets redrawn and the node positions recalculated every time a node is clicked. This means that I have to reorient myself in the graph every time I do this. It does not take many open nodes before that becomes very difficult and I also think it violates the principle of least surprise.

So if in any way possible, the only change resulting from expanding a node should be the new nodes it spawns.

Thank you guys again for your amazing work with this package that I already love!

[tefkah]

I agree, and I had put in some work in order to get it to this place at all.
To let you in how it works: The graph does not actually get redrawn when you click on a node, we just "hide" the transition, because if we didn't, the existing nodes would fly in in a rather dramatic fashion, like so

2021-08-23_13-27-01.mp4

To be honest, it's less dramatic than I remember, probably because I disabled trying to fit the local graph after loading it initially. While it's not as good as I would like it to be, I do agree that this might be less jarring than the current default behavior. I just want it to behave hahaha.

Hmm, maybe I could make it add the nodes one-by-one, that way there isn't suddenly a whole new blob of things.

[ghost]

I think some basic operators from set theory could be quite useful for black/whitelisting tags:
mainly:

• Union
• Intersection
• Set Difference
• Symmetric Difference
• Negation

Keep up the great work

[tefkah]

Hmmm, I'm struggling to see what this would add over the tag system we have now? It might be useful if you could save groups of tags and then compare those in different ways, but I feel like you could achieve all these (except maybe the difference ones) with some combination of black and whitelists.

I do think the tag system needs some overhauling, specifically that the way to add and remove them is kind of clunky (three menus deep) and not very fast. I would like the input to be a bit more dynamic, so you could type

+#definition -#physics quantum

to get all nodes with the word "quantum" in them which have the tag "definition" but not the tag "physics".

Will take some reworking of the filtering system though. but should be doable.

[Delapouite]

Hello

Thanks a lot for all the work already done on this project, it's a pleasure to use.

As a minor request, would it be possible to add a "node counter" somewhere? By "node counter" I mean displaying the number of nodes currently on screen. So at first launch, this number would be equal to the total number of nodes in the database, but then, after playing with the different filters, this number would reflect only visible nodes.

Thanks.

[tefkah]

Neat idea! Should be very easy to implement, just a ui thing that would need sorting out.
Any ideas of where you would want to display this?

Any other kinds of these global values you think would be interesting to keep track of?

[blester125]

I think a lot of Graph Theory summary stats could be somewhat interesting. Some of them are super cheap with the right data-structures

O(1)

• |V| :: number of vertices (node)
• |E| :: number of edges
• D :: density (how many edges are there of the possible edges?) |E| / |V| * (|V| - 1)
• Average Degree :: Average number of edges each node has |E| / |V|

O(V)

• (min|max)(in|out) Degree :: Extrema of the degree (how many edges) for each node in the graph. Our edges are directed to probably want counts of number of edges in and number of edges out
• Degree Range :: Max Degree - Min Degree
• Degree Variance :: sum(Degree(i) - Average Degree for i in V) / |V|

Diameter of the graph (longest possible path between two nodes) could be interesting, although that would be O(V * V^V) I think, Probably only possible if done async/with a limit on graph size

A node can have multiple edges to another node so we might want to have these stats in terms of weighted edges too (also would we want to add a visual indicator (with a toggle) of the weight of an edge between nodes?).

We could also give some similar information at the individual node level

• in/out degree of this node
• average nearest neighbor degree sum(Degree(j) for j in Neighbors(i)) / Degree(i)

[thriveth]

Graph timelapse

OK this one is quite silly but also cool. Obsidian has this "timelapse" functionality that plays an animation of your graph growing like shown here: https://forum.obsidian.md/t/how-to-make-your-graph-timelapse-animation-grow/

I don't know if the roam database even records this, or there are other technical stumbling blocks that might make it impossible but it could be a cool gadget-y thing to have!

[tefkah]

Well I have been working on org-roam-timestamps, which would make this possible! It's not working as well as it could, but it gets the job done. The sooner you start using it the more accurate it will be in the long run!
I mostly made this to enable other kinds of time based views, but this should not be very difficult to add.

I won't make it a priority but damn it does look cool.

Also please continue putting cool things other graphing applications do here! I want to try to steal as much as possible but don't use these things myself, so I inevitably end up missing some cool features that wouldn't be that hard to add.

[tecosaur]

With regard to creation times, I forget if it's still the default, but it was the case that the start of the file name was in the format YYYYMMDDSS_.

[tefkah]

Yeah I think it still is, org-roam-timestamps checks for that as well. We can do a very basic kind of time-based stuff using that and the file mtime, but it's extremely limited. We will support using that when we introduce some more functionality which can use that data, but I plan on mostly developing with org-roam-timestamps in mind (unless someone comes up with a better solution of course!)

[DrBanana419]

It would be nice to have tags displayed beside the nodes (along with their titles). I know tag colours exist but I can see that getting out of hand once I have a lot of tags.

[shader]

Narrow subnode previews

orui already graphs "subnodes" (nodes with ID that are headlines in a larger file) fairly well by linking them to their parent node.
However, when clicked on to view the preview of the subnode, it just shows the whole file.

It would be great if previewing a subnode narrowed the preview to only that headline and its children.

[tefkah]

This has actually very recently been added, see #203! If you update to the latest version this should work!

[shader]

Awesome! -2 days is probably the fastest response to a feature request I've ever seen. 😜

[Vidianos-Giannitsis]

A feature I was thinking about recently was the ability to have pointing arrows on the graph, so you can see if a node points to another one, other nodes point to it or both. Some notes become rather large because they connect to a lot of other things, but knowing if that is the case because they mention a lot of nodes, or because a lot of nodes mention them would be useful. I don't know how easy/hard this would be, but it would be a nice visual addition.

[tefkah]

This is already possible! See the "Visuals" tab in the tweaks panel, there should be some option that says something like "Arrows"

[Vidianos-Giannitsis]

How did I never notice that, I feel dumb now. Thanks for the quick reply

…

On Sat, 12 Feb 2022, 12:52 Thomas F. K. Jorna, ***@***.***> wrote: This is already possible! See the "Visuals" tab in the tweaks panel, there should be some option that says something like "Arrows" — Reply to this email directly, view it on GitHub <#6 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APGY5WZC6X2VM53CDGXCQ73U2Y3YJANCNFSM5BCHQ5ZQ> . You are receiving this because you commented.Message ID: ***@***.***>

[tefkah]

No worries! Lack of documentation of all these features doesn't help either haha

[DrBanana419]

It would be nice to not have the graph change every time you open it; currently even refreshing the page completely redistributes the nodes. Also I don't know if this is possible, but having the graph change as minimally as possible when a new node is added would also be a nice feature. I haven't used other software like this so I don't really know if this 'change on visit' behaviour is normal.

[wztdream]

A function to add node to local graph, something like org-roam-ui-add-to-local-graph will be cool.

Currently we have local-graph and we can expand it by clicking the node. This is some kind of blindly exploration, if you are lucky you hit a useful new node, if you are unlucky you miss important information. No body likes blind, right? What if we can tell org-roam-ui that add this node to local graph, then this new node will forma another source for graph expanding.

Is this useful? Yes, consider you have two conception node A and B, and you want to check how this two conception are related with each other. You can just add this two node to local graph, then play with it by expanding its neighbors. You can even add other nodes as bridge node to guide the road map that link them. The easiest you can "connect" A and B, the more conceptually related for A and B .

Why not check the relation directly from global graph? Well, as the graph grows bigger and bigger, it becomes harder and harder to check the relation between nodes, as there are too many disturb.

Can we go one step further? May be we do not need the global graph at all? Global graph is big, so it is commutation consuming. Can we dynamically add nodes from beginning? If we have org-roam-ui-add-to-local-graph function, we can do it by add the most related node. The benefit is we saved the computation and we get a clear sub graph.

[wztdream]

I noticed there is a Number of neighbors in local graph under Filter field in orui, so the neighbors of the added node should follow this setting.

There is a workaround to achieve this already, but not perfect, suppose we are interested in node A and node B, we do the following:

1. create a "probe" node P in emacs, reference node A and node B in P
2. navigate to node P in 'orui`
3. open the local graph of node P
4. gradually increase Number of neighbors in local graph, and check the connection between node A and B
5. when you are done, delete node P in emacs

As you can see, this can achieve what we want already, the problem is we need create and delete the "probe" node. It will be better orui can create this proble node on the fly and automatically delete it when finished.

[tefkah]

I think I can add this kinda quickly yeah! I'm in a bit low maintenance mode but because this feature is so small I think I can just add it, gimme a sec.

[wztdream]

cool, glad to hear that!

[tefkah]

Latest commit should add that! Give it a second to build though

[wztdream]

@tefkah you are amazing! Well done! I just tried it and it works. Here are several minor issues that you may consider polish:

1. Number of neighbors in local graph seems not work in this kind of local graph, we'd better enable it as it allows to expand all nodes, it's quite useful, as mentioned in above use case in step 4
2. org-roam-ui-follow-mode seems conflict with org-roam-ui-add-to-local-graph, as it will delete previous added node. It's better orui can focus to the node without delete other node.

[Zetagon]

It would be nice to be able to disable global mode all-together, i.e. just jump into local mode immediately.

The global view has long been pretty useless to me, I just have too many nodes for it (which isn't a problem of org-roam-ui btw!). As it stands I currently call org-roam-ui-open, wait for a while while the fans start spinning and the website becomes responsive, and then call org-roam-ui-change-local-graph. It would be nice to be able to skip to the last step.

[tefkah]

that makes sense, i think a toggle for default mode should not be that hard, let me see

[tefkah]

okay it's harder than i thought, could you make an issue for this?

[Zetagon]

Sure, give me a sec.

[maxfujimoto]

Being able to define the browser explicitly would save me a few seconds every launch, I use firefox for regular browsing but have to use brave for ORUI.

[tefkah]

You should be able to specify the browser, see https://github.com/org-roam/org-roam-ui#open-on-start

[maxfujimoto]

Not sure if this is an issue with my config or something but after evaluating your suggestion firefox still opens even if brave is the only browser open. Is it possible to explicitly declare a specific browser so it opens when I run org-roam-ui-open, ignoring other states and variables.

[tefkah]

No sorry I'm stupid. The correct config is shown here, it's not in the readme

org-roam-ui/org-roam-ui.el

Lines 127 to 132 in 5ac7496

	(defcustom org-roam-ui-browser-function #'browse-url
	"When non-nil launch org-roam-ui with a different browser function.
	Takes a function name, such as #'browse-url-chromium.
	Defaults to #'browse-url."
	:group 'org-roam-ui
	:type 'function)

[elenadilavore]

It would be nice to be able to show links to files as well (the usual [[file:myfile.org]]) and add a node for each file, even if they don't link to anything (excuse me if this is already possibile).

It would also be useful to have the possibility to show only the files with links between them and the links between the headers in them. For example, if I have a header1 in file1 linking to header2 in file2, I would like the graph to show a connection between file1 and file2, while not showing separate nodes for the headers.

Thanks!