I've read your awesome travel in T15659 but I've also read this inline comment:

It's nice and it works. So... thanks!

@aklapper @valerio.bozzolan I think the styles for remarkup should stay seperated. We shouldn't blur modular css definitions just to safe some lines or multiple declarations.

• Seperates styles

## Contents

- is Phorge good for my Organization?
- differences between Phorge and GitLab, GitHub, Launchpad, Mantis, ...
- what's new in Phorge (that is not in Phabricator)
- practical workflows and pitfalls
- how to join the Phorge community
- how to propose code patches

Uh, right. So maybe we can:

Also remove unused $result array

I propose to remove that unused $result array. It's been unused before and looks we were not aware of any issues created by that fact.

Original change which triggered this: rP324470e39b0d4539a7487c2144157d686f5d0906

I cannot test it now, can you check who was setting that margin? Maybe we can try to avoid that !important

I was able to trigger the "missing gd" warning (By uninstalling php*gd), so we're good there.
A bit puzzled about how you got the error if you already have it installed?

@aklapper This task created a small regression. It is really so small I don‘t think it needs a task. Maybe you can accept my revision D25522.

User content is also content, thus yes.

Good question. Maybe also related to L2.

I'm still puzzled by the unused $result variable in line 46.

Is it assumed that using the site will automatically license the user’s content under these, or should there be a line for that?

In T15322#15031, @aklapper wrote:

+1 on Content licensed under Creative Commons Attribution-ShareAlike 4.0 (CC-BY-SA) unless otherwise noted; code licensed under Apache 2.0 or other open source licenses.

Thanks!

In T15645#15201, @speck wrote:

@bekay while in this area of code would you have any pointers on these other issues I’d like to fix at some point?

1. File browse widget doesn’t work unless logged in, for publicly accessible repos
2. The search results pop up width is often too narrow to show the full results path, and truncates the end of the path instead of beginning.

Values given in em units may produce unexpected results...

Adds return value to annotation and fixes wrong path when locating file from within a directory.

Tested locally and works in most cases, however would love to avoid creating broken (404) URIs due to T15579 before merging

Note that at least for Phame, http://phorge.localhost/J1 seems to always redirect to http://phorge.localhost/phame/post/view/1/blogpost/ instead of keeping the monogram in the URI.
So the baseURI is already wrong (not being http://phorge.localhost/ only) before concatenating the $ref (monogram and anchor).
As an ugly workardound, could probably make "Quote Comment" work by calling getObjectNamePrefix() in PhamePostRemarkupRule and LegalpadDocumentRemarkupRule and then use them in a preg_match to remove the monogram from the $ref but function is protected and... still ugly.

@bekay while in this area of code would you have any pointers on these other issues I’d like to fix at some point?

1. File browse widget doesn’t work unless logged in, for publicly accessible repos
2. The search results pop up width is often too narrow to show the full results path, and truncates the end of the path instead of beginning.

Looks good! Thank you so much for this!

In D25505#14533, @avivey wrote:

How about other functions that might require a logged-in user? "current Viewer's Projects" for example?

Yes. I think we should wait for a kind Administrator to implement the first one.

@speck @valerio.bozzolan My revision is ready to be tested 😄

• Adds map

In D25520#14909, @avivey wrote:

Thanks
also - need to run bin/celerity map before landing?

Thanks
also - need to run bin/celerity map before landing?

please make the title more descriptive of the actual change (what it's doing) - "improve usability" is very vague.
maybe "don't hide title in search" or something like that.

Tested and I like it. Thanks :3

@aklapper @valerio.bozzolan See D25520.

Uh thanks! You are now co-speaker

BTW I like the proposed screenshot. So I also agree to: feel free to share the solution 👍

My fix would work with this css class

I did not realize you had a fix. Please share it. :)

In T15715#15174, @aklapper wrote:

I guess you could get the result that you're looking for by editing the file webroot/rsrc/css/aphront/typeahead.css and removing the line white-space: nowrap; from the definition of div.jx-typeahead-results a.jx-result. I just don't know which side effects this may have in other places...

For parallel popcorn consumption, a slightly related (and slightly hung over) FOSDEM talk from 2015 with some shattered dreams included, from the perspective of an organization at that time: https://archive.fosdem.org/2015/schedule/event/wikimedia_adopts_phabricator/

I guess you could get the result that you're looking for by editing the file webroot/rsrc/css/aphront/typeahead.css and removing the line white-space: nowrap; from the definition of div.jx-typeahead-results a.jx-result. I just don't know which side effects this may have in other places...

If it's only for a small number of such words, they should probably just be added to the blacklist remarkup.ignored-object-names - in fact, we should probably add S3 at least as a default; And probably find a way to expose this config option. Maybe a button on the Remarkup box that will help adding things to the blacklist?

This patch is a cleaner approach to tackle T15676 than D25479 was.
In future steps,

• T15700: An "Integer" search field could be addressed (patch available for review),
• the type of the "Page Size" field in ManiphestTaskSearchEngine.php could be switched from PhabricatorSearchTextField to PhabricatorIntTextField - see T15723: Convert "Page Size" field in ManiphestTaskSearchEngine.php to PhabricatorSearchIntField,
• an AphrontFormIntControl class could be introduced to set type="number" for the control in the HTML,
• we could introduce an overwrite validateControlValue() function in PhabricatorSearchTextField.php as in theory, future code could accidentally pass invalid data types to setDefaultValue() - see T15714: Validate PhabricatorSearchTextField value

Nah, I vaguely remember I accidentally set up something which didn't make sense and the followup PEBKAC moment when realizing but don't remember details now

In D25515#14842, @valerio.bozzolan wrote:

I wonder if it then, upon deletion of the profile image, it attempts to delete the builtin image

In T15712#15124, @avivey wrote:

Is the motivation only to allow not-magicking things like "S3" and "F1", or is there more?

Looks like the tickets end in a Wontfix in https://secure.phabricator.com/T5301; I didn't follow the whole thing, but often the reasoning in Remarkup boils down to performance.

mm, see this one: https://secure.phabricator.com/T5301#211340

Is the motivation only to allow not-magicking things like "S3" and "F1", or is there more?

Some help is needed there, testing on PHP 8.1+ and getting the right stack trace

I wonder if it then, upon deletion of the profile image, it attempts to delete the builtin image

Useful riepilogue for wild integers

Abandoning my patch becaue creating a child class for each and every single field does not scale.
Instead there should be a setDefaultValue() function on a PhabricatorSearchField level to be called by the SearchEngine.

Is that something we can improve in the settings page/docs - give better instructions on this setting?

Indeed, this is invalid due to me not understanding the config settings at that time.