oh, wow, the preview already handles tiny pictures differently...

See Contributing Feature Requests and Describing Root Problems. The context and discussion in T3945 and T9652 may be helpful in formulating a problem description.

This would be awesome.

I've also never used seamless so I'm not sure how support looks in practice, but this isn't immediately reassuring:

I think that only prevents referrer leaking -- it doesn't deal with the other issues in T4190#60441 (or request amplification attacks), right?

Can we avoid the need for this entirely using the approach outlined in T11126 (using CSP or <iframe seamless referrerpolicy="no-referrer">)?

The vaguely related T5378 is also in the queue somewhere. It may not really intersect with this, but if we do end up trying to auto-embed any URI that ends in .jpg again it probably will. I'm not sure we should, but just a heads up for context.

The general shape of what we're trying to do here is that when a user writes the URL of an image in a comment (e.g., http://funny.lol/silly-dog.jpg, perhaps with some magic *$!symbols$*!) it would be nice to just show the image. Today, they'd have to download and re-upload it, which is somewhat cumbersome.

I haven't come up with any kind of rule for this in the last couple years which feels sufficiently un-magical, even in theory. It hasn't happened all that often recently, either, at least that I can recall.

PhabricatorRemarkupFigletBlockInterpreter is a remarkup rule for rendering figlet fonts, invoked like this:

(I believe we already show any changes that pressing the submit button will make to subscribers accurately in the preview. This wasn't always true prior to EditEngine and I think the preview/actual effect would sometimes disagree in weird cases, but I believe the preview is now always fully accurate. However, it's quite easy to miss.)

When a user writes a Maniphest comment, I think fully and correctly populating the "Change Subscribers" field, including its new/upcoming additions, would be a good and unobjectionable feature. This would allow the currently unconditional additions to be removed manually prior to form submission. This would still be tedious, but at least I could make a comment without having to either mangle the quote or go back after commenting to perform a separate manual action unsubscribing the user that I didn't intend to add.

In T11471#190152, @epriestley wrote:

If you don't like the @mention-implies-CC behavior, you can disable it by applying this patch to your install:

[...]

If you don't like the @mention-implies-CC behavior

.aphront-form-input input is to blame.

If you don't like the @mention-implies-CC behavior, you can disable it by applying this patch to your install:

In T11471#190079, @chad wrote:

I don't consider this to be a bug and any fix would likely lead to additional user confusion over "magic".

I also don't necessarily consider this a bug (I think a human explicitly @mention-ing a user definitely should add them again, and that quoting someone is pretty close to mentioning them, and that reasonable users could probably expect either behavior, and perhaps that the "add them again" behavior is more obvious or more expected) but T11035 discusses this and some other behaviors which have varying amounts of grey area.

The use case in that linked task is "using Remarkup to demonstrate the behavior of a different markup language", which isn't something we expect Remarkup to support.

The example is pretty descriptive, I'd say. Because of linking to the description of that exact part of the word.

Why do you want to link part of a word?

These use the prose algorithm now, and I don't plan to try to implement syntax highlighting for prose diffs.

This would be very useful for things like blocks of code. If you're suggesting a few options for a certain bit of code, or using a list to explain changes to multiple interfaces (code is much more concise than prose), nested code blocks would be very useful.

In T11284#184462, @chad wrote:

Can you give an example of what specifically you are trying to build in Phabricator?

Maybe something like long lists with "titles" or "summaries" for list elements?

# Something top-level
  Long, multi-sentence description of this top-level list item.
 - Sub-element with "title" <br/>
   Long, multi-sentence description of this inner list item.
 - **Another sub-element, highlighted even** <br/>
   Another long description.
   Very long and very descriptive. 
# Something else

which renders like:

1. Something top-level
   Long, multi-sentence description of this top-level list item.

Cursory research yields Markdown uses two spaces to indicate a <br />.

Can you give an example of what specifically you are trying to build in Phabricator?

oh man, I even filed it.

Any particular system this doesn't work on?

News to me that we don't support it.

Docs regenerate on a cron so this won't actually show up live until sometime tonight, but D16186 has a screenshot.

Filed as T11228

Please add the triple dash to the documentation page, I couldn't find it clicking on the main life-saver icon link.

In live comments, these links are bad offhand:

• The stuff above should be better now, but I'm not sure if I got everything. We should run through that list again.
• The "Subscribers" and "Projects" links here do not link to the correct domain, and fixing them isn't trivial because they're event-driven extensions:

I'm not completely opposed to ever changing this, but I think there are pretty good reasons for the current behavior.

I think it starts out as a URL, and then replaced on the client-side with the name after some AJAX. Most of the time I don't have time to see the "before" text.

I don't understand why it's a tag. Does the JIRA link look like a URL or an actual name?

css is it's own world of magick.

I'm faking my way through it.

Here's Chrome's Style page for the element:

I'm just surprised to hear something is still overflowing after D16081.