In T15728#15768, @valerio.bozzolan wrote:

I tried to understand the situation. Thanks.

In your opinion: on the repo view (with clone buttons) is it really important to link to the other similar "reduced" view (without clone buttons)?

I tried to understand the situation. Thanks.

Ok, see here: https://we.phorge.it/book/phorge/article/configuring_outbound_email/#outbound-quot-from-quot-and-quot

• I have setup cluster.mailers using smtp type (phorge-mailer@gmail.com (example only))
• those messages are receive in phorge-mailer@gmail.com from google mailer, informing that noreply@phorge.domain.com is not reachable so it bounce.
• I assume, it happened because phorge send outbound email:
  • using noreply@phorge.domain.com as "To" address
  • "cc" address to recipients
  • "From" with format "Username (Fullname) <phorge-mailer@gmail.com>"
• Is it possible to disable or change "To" address other than noreply@phorge.domain.com, because I didn't setup phorge.domain.com to receive email.

btw, for the "search" use-case I'm describing, I'm imagining something like a Function on Users/project, so I can search, for example "Tasks that are assigned to users which I flagged with a green flag" or "Tasks that have a tag that I flagged with a blue flag".
And also, "Revisions that I flagged with any flag".

I looked into this again.

Hello! Are you sure changing the links color is a good idea? Perhaps we should just make the background darker?

Wiki volkankaos

Just asking for a friend: Is there some progress on this?

Maybe this could be integrated in the Diagrams extension...? I mean: the entire infrastructure is there - you just have to decide, what lib you wanne use when creating a new diagram. @mturdus What do you think about this?

It would be a pleasure to receive a patch from you :) The file should be this one:

Maybe this is wild, but: should we consider removing the compiled xhpast.exe file from the repository, and host is externally?
I think it's only used for working on PHP on Windows; The equivalent xhpast isn't included, presumably because compiling stuff on Windows is harder.
My argument for this is that the normal way to install arcanist is git clone, which downloads all the history (and 95% of users won't need this particular file).

Passed a week. Nobody commented. I blindly trust you in this field :3 Approve.

In T15673#15587, @valerio.bozzolan wrote:

TRUST ME - YOU DON'T WANT TO LISTEN MY ENGLISH :D :D

Btw now the video is here :D :D AGAIN SORRY PHORGE FOR MY MISTAKES <3 <3

https://video.fosdem.org/2024/h2215/fosdem-2024-3610-unpack-phabricator-welcome-phorge-forking-the-opinionated-open-source-project-manager.av1.webm

• Making @valerio.bozzolan happy

Premising that I've already accepted I noticed also this minor possible thing:

Lovely thanks :)

I really have struggled to find any device in our company that can't do await/async. I strongly bevlieve it is a non issue. Let us land this thing now and see if we get any feedback of an error.

• Changes the order of the variables and function calls

• Extends select behavior and only select content on first click

The ".then()" part is pure hackness; The async/await is the sane way to do async programming.

In D25536#15448, @valerio.bozzolan wrote:

Again, non-blocking opinion:

Are we aware that the "async" keyword (that was never used in Phorge) may just cause a crash by syntax error (almost-immediately even without clicking?) by that kind of browsers, so, breaking the page, just because we want to provide a copy function and we want to avoid .then()?

I think we can introduce breaking changes, but it's strange to do that, now, with this minor feature.

If we are aware of this minor risk, indeed let's land.

Again, non-blocking opinion:

In D25536#15446, @valerio.bozzolan wrote:

Additional non-blocking thing:

Maybe should be copy(text) with var data defined outside

Bonus point: copy() not defined during every call of JX.Stratcom.listen, but outside (?)

Additional non-blocking thing:

In D25536#15437, @valerio.bozzolan wrote:

Yes, we can avoid async.

So, this is just a tip, to avoid async and also to have everything a little more modular for no reason:

1. remove async from copy()
2. rename copy() to copyWithoutFeedback() and have the function that always return a Promise
   • so copyWithoutFeedback() has return navigator.clipboard.writeText(text); to always return a Promise
   • so copyWithoutFeedback() can use copyWithFeedback() but after that it return Promise.resolve(true) to always return a Promise
   • so copyWithoutFeedback() can fail with just return Promise.reject() to always return a Promise
3. so we can create the function with feedback, copyWithFeedback(), that just calls the previous one, so, copyWithoutFeedback().then(function() { show_success_message() } ); with also a chained .fail( function() { show_error_message(); } ) or something similar

• Updates map

• Ignores async jshint

First of all, I tested this, and this is super-lovely, really better than I thought, I love this. Thanks.

oh, for this one we can just ignore it. arc only shows these for new lines

In D25536#15422, @avivey wrote:

I'll try to see if there's config for the jshint to allow async.

I'm happy about the JS stuff, and I'm ok with any UI solution here.
I'll try to see if there's config for the jshint to allow async.

Well, now I have tried to satisfy every wish.

• use async/await for copy promise hell
• make the io button to just a type icon
• select entire text when clicking inside the input field
• patch JsShrink to shrink await/async syntax

We can probably just pull the JsShrink fix in for now, and later replace both it and jsxmin (which I'll bet nobody have) with something else that is maintained, like JShrink.

(This Quickfix would help: https://github.com/vrana/JsShrink/pull/6/commits/5b2dd500d25b29ace2fbd76fc95b4518ef22abfc 😆 )

await/async won't go through the shrink process without destroying the entire syntax. And if it will go through this jsxmin binary, who can know? Note for the future: Maybe replace the entire shrink process with a new and used php shrinker like JShrink.

In D25536#15408, @valerio.bozzolan wrote:

(Just to clarify, and sorry if late comment again - I was proposing to avoid to add buttons, and simply auto-select and auto-copy the input text the first time it receives a click. Bonus: with "copied" message feedback - I have untested this sorry)

@avivey worst case is a syntax error because the operators are not known. Even that could be wrapped inside a try/catch.
@valerio.bozzolan could be done with the current behavior but this kind of implicit actions seems not the phorge way...?

(Just to clarify, and sorry if late comment again - I was proposing to avoid to add buttons, and simply auto-select and auto-copy the input text the first time it receives a click. Bonus: with "copied" message feedback - I have untested this sorry)

Our policy in general is "support things way after the go EOL", but with the cost of supporting IE 11 (this kind of hell), I think we can make an exception and throw it under the bus. Worst case, we're talking about an error in the logs and "nothing happening" from the user POV, right?

I've successfully updated our Phabricator instance to Phorge today. After paying very careful attention to everything it went smoothly without any issues. Glad that this project has not died. Phabricator grew on me as well.

In D25536#15395, @avivey wrote:

Yes, I insist on using the absolute required minimum of Promise-style coding.

Should we add FreeBSD to this list? It uses Phorge now (as of June 2023) and has many users.
(Much of their documentation still refers to it as "Phabricator", despite this.)

I agree, disabled users should be hidden in the global search typeahead results.

In T15736#15681, @bekay wrote:

• Get rid of the JX namespace and the the require comments - use import and export like it is done in modern js

Remove unreached return call as pointed out by speck

In D25502#15384, @speck wrote:

Is it possible to check if anything is relying on this not working with negative numbers?

Sorry for my late comment

Yes, I insist on using the absolute required minimum of Promise-style coding.
I don't know if we have any other example of a Promise-based API used - there might be an example somewhere on how to break away from it and go back to sane code.

I have to wait for the success or failure of the copy action, so I think this ui example makes no sense for my case. The notification should not be triggered by a button click.

Don't do that thing to the JS file. To add a notification, use the existing notification feature we already have - see https://we.phorge.it/uiexample/view/PhabricatorNotificationUIExample/ (https://we.phorge.it/source/phorge/browse/master/src/applications/uiexample/examples/PhabricatorNotificationUIExample.php).

I'm not against replacing the mechanism - It's just that the original task description doesn't specify why that would be good (i.e., what the benefit would be).
That's clear from the discussion now, but should generally be included in the ticket description - the "describe "what", not "how"" principle.

A big benefit of using client-side variables in CSS, is that one can use the browser's prefers-color-scheme media query to select light or dark mode based on the user's browser or system setting, automatically, and that the transition from light to dark mode, or to other accent/highlight color schemes, requires no reload.

Is it possible to check if anything is relying on this not working with negative numbers?

Well, I see a tremendous critism and scepticism concerning modern client side techniques here. The world of frontend tooling has changed tremendously in the last 5 years. And I understand concerns, but nobody has to write JavaScript for certain browsers anymore. Javelin for example tries to solve so many problems that Babel solves with one config entry. But that's okay and I like the architecture here and know we can't change everything at once.