Archive for July 26, 2022

Tuesday, July 26, 2022

Git Tower 9

Tower:

Auto-expand changesets: A new view option has been added to configure behaviour of auto-expanding diffs in the History changeset views. You can find it under “Diffs in Changeset” in the “View” main menu.

This is great. I always want to see the changes expanded unless they’re huge.

Show branch/commit in History: You can now reveal a branch, tag or any commit in the Tower’s History view by selecting “Reveal in History” from the context menu.

This refers to clicking on a branch/commit in the sidebar, not one shown as a bubble in the history. It then reveals it in the history, which is nice.

Snapshots: Create snapshots of your working copy or individual changed files. Changes are safely stored in a stash but they remain in your working tree. This feature is available from the context menu of changed files or from the “Working Copy” main menu.

In other words, you can now easily save in-progress work without creating a commit. I used to do this by creating a stash (which clears the working copy) and applying it (but saving the stash).

Large diffs: Large diffs are not displayed automatically anymore. Instead, you will be prompted to display the diff. The threshold for displaying the warning can now be configured in the General preferences.

This should prevent freezes when skimming through lots of commits.

Previously:

Update (2022-08-02): Bruno Brito:

It all starts with a brand-new Merge UI! The primary goal was to make it more explanatory and consistent for merge sequences and when editing revisions.

Swift Proposal: Move Function

SE-0366 (forum):

In this document, we propose adding a new function called move to the swift standard library, which ends the lifetime of a specific local let, local var, or consuming function parameter, and which enforces this by causing the compiler to emit a diagnostic upon any uses that are after the move function. This allows for code that relies on forwarding ownership of values for performance or correctness to communicate that requirement to the compiler and to human readers.

[…]

As a function, move is rather unusual, since it only accepts certain forms of expression as its argument, and it doesn’t really have any runtime behavior of its own, acting more as a marker for the compiler to perform additional analysis. As such, many have suggested alternative spellings that make move’s special nature more syntactically distinct[…]

[…]

Another useful tool for programmers is to be able to suppress Swift’s usual implicit copying rules for a type, specific values, or a scope. The move function as proposed is not intended to be a replacement for move-only types or for “no-implicit-copy” constraints on values or scopes. The authors believe that there is room in the language for both features; move is a useful incremental annotation for code that is value type- or object-oriented which needs minor amounts of fine control for performance.

Previously:

Update (2022-07-28): See also: Hacker News.

Netflix Adds External Subscription Button

Filipe Espósito:

Earlier this year, Apple began allowing “reader” apps to provide external links for customers so they can log in and pay for a subscription from outside the App Store. Now Netflix is rolling out an option in its iOS app that takes users to its website in order to finish a new Netflix subscription.

[…]

When you tap the subscribe button, a message says that “you’re about to leave the app and go to an external website.” The app also notes that the transaction will no longer be Apple’s responsibility and that all subscription management should be done under Netflix’s platform.

Netflix was already not using In-App Purchase, but this change lets them explain to customers without accounts how they can create one. Before, instead of clicking a button to open the site, they had to make a phone call.

Eric Seufert:

Once again we see the use of heavy-handed, intimidating language in intransigent, disruptive modals designed to suppress consumer use of off-platform services. This is clearly a significant hurdle to open payments and commerce. And the privacy point is absurd.

Michael Love:

I’m now delightedly realizing that when my new website launches with its accompanying “buy directly from Pleco and save 20%” ad campaign I can totally reciprocate here and spread FUD about buying through Apple.

It’s accurate FUD, too - Apple actually does reject refund requests sometimes (and we can’t overrule them when they do), they do lose purchases sometimes (and we can’t always retrieve them when we do); I can with absolute sincerity say the safest place to buy Pleco is from us.

Heck, I’ll put up a dang comparison chart showing the price difference + availability of refunds + where money goes + support response times + fact that actual humans are reading your email and not responding from a script; “why waste money + put up with Apple’s crappy support?”

But only “reader” apps can do this.

Previously:

Update (2022-08-08): John Gruber:

We can (and should) quibble with some of the design details and language of this warning dialog — why is the headline font so big? why is Netflix’s own name in quotes? — but on the whole this is the way things should be. Developers should be able to steer users to the web for payments and subscriptions, and users should know they’re being steered to the web, and that anything they pay for outside the app won’t work like in-app payments do.

Mail Links and Percentages

Dr. Drang:

Yesterday, John Voorhees wrote a nice article at MacStories about creating links to specific email messages. His system is in the form of a Shortcut, but the real work is done by an AppleScript. The AppleScript is an extension of one John Gruber wrote 15 years ago.

[…]

The questions I needed to answer were:

  1. Are reserved characters used in message IDs?
  2. If so, do they need to be percent-encoded in a message URL?

[…]

None of the reserved characters caused a problem except the percent sign itself.

However, that does not mean that the strings are valid URLs, and in fact even putting the message ID in unencoded angle brackets will prevent it from working with NSURL. I think what’s happening here is that Mail is receiving the URL as a string and removing the percent escapes directly, without actually parsing it as a URL.

So, if you store unencoded links you are setting yourself up for trouble if Mail changes how it works, if you ever want to redirect the message: scheme to a different app, or if you want to detect message: URLs that are embedded in a document. Lots of e-mails unfortunately don’t follow the specification, and I’ve seen Message-ID headers that include the " and ) characters, as well as spaces, which could mess up the way Markdown interprets the links.

If you want to handle more than the percent symbol, here’s an AppleScript that will escape the other characters, too:

use AppleScript version "2.4"
use framework "Foundation"

on URLFromMessageID(_messageID)
    set _components to my NSURLComponents's alloc's init
    _components's setScheme:"message"
    _components's setHost:("<" & _messageID & ">")
    return _components's |URL|'s absoluteString() as Unicode text
end URLFromMessageID

Another issue to be aware of is that the Message-ID header sometimes includes text outside of the angle brackets. This should not be included in the URL. However, if you are using Mail’s message id AppleScript property, as Gruber’s script does, it will remove the extraneous text for you (just as it removes the angle brackets themselves).

Previously:

But 15 years after adding support for these URLs, Apple still hasn’t exposed a direct way to copy them from any given message other than drag-and-drop.