If macros really shall solve T9153 (updating of links to files):

(I would like remarkup macros)

From https://secure.phabricator.com/book/phabcontrib/article/feature_requests/#describe-problems

I understand that the original reporter actually wanted "page templates", not "macros".

I am presuming this should work like wiki templates:

This comes up quite regularly among my users. Even for me it is rather annoying to always have to type full paths - the common case in our (including my) workflow seems to be to link to sub-pages, which becomes unnecessarily cumbersome in Phriction. Additionally this is contrary to experience with well known filesystem functions like symlinks, for example.

In T9165#131879, @epriestley wrote:

There is only one flavor of "Visible To", which is the second, more general one:

Who can see this object and sub-objects / contents?

"Visible To" always means this. If you can point out cases where it doesn't, we'll fix them.

In T9165#131879, @epriestley wrote:

It sounds like the root issue here is really confusion around projects, and an expectation that associating a project with an object puts the object "in" the project. It doesn't, and, by design, project associations never affect visibility.

We recently added external users to our install and have some wiki pages in general locations, which were visible to everyone (and easily reachable / easy to create name clashes). With adding Spaces and adding more external collaborators, we also introduced a new wiki structure (/our_org is where all our internal stuff goes; projects each get /the_project so they can be made accessible to externals if necessary). Thus I had to move a huge bunch of wiki pages (see T6004). Afterwards the old pages were left in a state were their history was still accessible to everyone, which I fixed by destroying them on the commandline. When destroying several dozen of pages, Actions → hover: Flag For Later → right-click → Copy Link Location becomes cumbersome.

We could also split projects into two completely separate but essentially identical applications, "Groups" and "Tags". In the simplest form, both applications would run exactly the same code, except one would say "Groups" everywhere and one would say "Tags" everywhere, and each object would have an internal type flag specifying whether it is a "Group" or a "Tag".

Why are you destroying wiki pages?

There is only one flavor of "Visible To", which is the second, more general one:

We could do parts of this prior to T9132, but completing it first gives us much better tools for solving this everywhere, and a realistic chance of building a not-totally-awful resolution UX.

Subscribing myself to a Wiki page is already possible. It is also possible to subscribe other people by @mentioning them in the page's content.

I think we'll pass on this in the upstream.

(oops, sorry I didn't see the other comment)

We want to get out of the hypothetical game with feature requests. If you have a real need, please describe the problem.

The default policy for x/y/ is inherited from x/. The expectation is that this is always the correct default. What's your use case where this isn't the correct default?

You have to be able to edit x/ to create x/y/. The UX is kind of junk, but I think this does technically work. Is that sufficient?

cc @joshuaspence

I have a rough goal of unbeta-ing Phame in the next few months and hope it should be a decent content distribution system.

Should I be using Phame?

yudodis to phriction

What about a situation in which users would need access to the unedited document?

That would work but I guess.

I think Are they both clear, it's just easy to forget when filing tasks? sums it up the best: I am primarily used to other projects and other trackers. Another issue is that sometimes I'll "fast forward" my thoughts: have a problem, think through the solution, and then forget to describe the problem.

What about setting edit and view to only me until it's complete?

See T7962 and T8054 for previous requests to describe problems.

We also talked about forcing people to use 'story cards' for requests. So it'd be something like:

(Reviewing Wiki Pages seems reasonable at some point).

@eadler the main problem with filing feature request solutions, then trying to justify it with problems is it makes our job significantly harder, that we have to reject multiple things or try to formulate long reasoned answers for each item. When you just file a problem, we're much more easily able to manage and group it with other (similar) problems. The solutions might change, but we're a very small team and when we solve problems, we try to group them to satisfy the most use cases. Just trust us with your problems.

I updated the task description hopefully better describing the problem

Please file feature requests only describing your problem, not your solution.

Great, thank you! :)

In any case, is it expected that line numbers are being copied in the unified diff case?

I wasn't trying to revert, I was just trying to copy-paste some of the markup of an old version of a wiki doc. Since I was copying from a previously deleted section, I understand why the result was empty: it was copying from the right side of the diff which was empty. That said, that was very non-intuitive.

Oh, I can copy and paste fine in Differential. Guess... Chrome fixed that at some point, or I'm forgetful.

Do you have an example where copying the right side of a diff currently does not work like you expect/want it to?

I copy/paste code, i don't know how to write it myself.

When copying from Phriction and transaction diffs (for example, the diff shown in "Show Details" on a transaction like "alincoln edited the description for this task."), you're also copying out of a diff which we've inserted artificial linebreaks into. These linebreaks are inserted prior to diffing, and these diffs are generally of very low quality. There's some discussion in T3353 of improving these diffs to be word-based instead of character-based, which is likely to substantially mitigate issues around linebreaks and the generally low quality of these diffs.

In 1-up, there's no ambiguity and we can improve this behavior.

Actually works really well in Chrome (43 and earlier) on Windows:

It's not really a Phriction task, just any diff in general.

We aren't going to ship with the Phriction content.

Oh. It's no big deal. I just added a space between M and 8 for now as a work-around. Just wanted to document it here, just so you guys know. Which it seems like you already do :P

Yeah, its any Remarkup Object when used as a header, it's not specific to Phriction or Pholio. I'm just trying to understand if this was a just goofing around bug or it's blocking my entire team bug.

Probably bugging out because M\d+ is what is used for PHUIDs of Pholio Mocks?? Unrelated to my current use-case, we just have a thing called M8 in our system, and I was documenting it lol. Either way it appearing as an x in the ToC is bugged imo.

Add == M8 as a header in the document.

What specifically are you trying to do?

In T7005#125352, @epriestley wrote:

You can add such a field yourself:

https://secure.phabricator.com/book/phabricator/article/custom_fields/

It would be ideal to have a direct wiki link in this nav bar when looking at a project:

You can add such a field yourself:

Since projects can have custom fields, how about a field that's for a link to a wiki page?

From T8779

+1 to get this to happen. Easily and "officially" connect a Phab project and a wiki page is very useful, especially for new users when needing to navigate around. You can certainly make a convention but then it needs to be enforced and this never works 100%.

Phriction can handle text document fine. I would like to see Google Drawings or any charting display integration to Phrication.

This is why we ask people to file tasks about the problems they are having with Phabricator. This task focuses on a feature thats wanted, and then defended with reasons instead of allowing us to discern the core issue and group with similar needs.

@chad I won't object to closing as Wontfix but to be clear: this use case is not limited to public installs or nor to installs with dot installed. I was just giving an example of a 'complicated' remarkup example.

See T3963 for templating. You could also put the whole template in a code block or literal block so that people could just copy it directly.

This isn't a good fit in the upstream for me.

Its come up in two cases:
(a) I want to have a template page per team or group that users shouldn't edit, but should be able to copy to make their own
(b) someone else made something interesting and complicated such using using dot {{{}}} and I want to see how they did so to be able to make something else.

Why is this important or useful?