-
Bug
-
Resolution: Fixed
-
Low
-
None
-
None
-
None
Reported by a user on email, since a few versions ago (probably since the upgrade of the Xcode SDK to 10.8+) the commit text view has had Smart Quotes and Smart Dashes enable by default (right-click, Substitution menu). This cases a double-dash and quotes to be converted to extended characters which can cause problems on other platforms.
While the user can disable these options, they are not remembered.
This is exactly the same as the spell checking option in the commit text dialog, which is currently remembered. Rather than adding more options here, the best thing to do is to disable these options by default instead, since for a commit message you don't really want automatic substitution with special characters.
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[SRCTREE-2030] Automatic quote & dash substitution should be disabled for commit view
Nope, definitely not fixed. Using 2.4.1 (97) on Yosemite (10.10.5) and each time I make a commit I have to go uncheck all the 'Substitutions' flags if I'm typing certain things (–->, ...). It may seem minor but I type ascii arrows --> and dot dot dot (...) very often so this issue pops up a lot.
And on a side note, the dot dot dot substitution reduces three clear periods into some really tiny barely readable font. Why are you doing that anyway? Who replaces the three dot notation?
I am seeing this issue in 2.4.1 on Sierra; I have stopped committing through SourceTree because of this.
Aaron Madlon-Kay
added a comment - This bug is marked "fixed" in 1.8.1, but I am using 2.3.2 on macOS Sierra and the problematic behavior is still happening (automatic quote and dash substitution is still enabled by default and changes to these settings are not remembered). Is this a regression?
Aaron Madlon-Kay
added a comment - This bug is marked "fixed" in 1.8.1, but I am using 2.3.2 on macOS Sierra and the problematic behavior is still happening (automatic quote and dash substitution is still enabled by default and changes to these settings are not remembered). Is this a regression? 
Kevin Wojniak
added a comment - Just commenting to say I'll be looking forward to this feature, as we use Jenkins and it gives garbled output for these characters (not sure who's failing with the encodings there...). Will be nice to go back to ASCII 
Kevin Wojniak
added a comment - Just commenting to say I'll be looking forward to this feature, as we use Jenkins and it gives garbled output for these characters (not sure who's failing with the encodings there...). Will be nice to go back to ASCII This is definitely an improvement, but I would think that anyone who turns the option on would expect it to stay on. I'm not a Mac developer, but based on my experience as a user, I believe the correct behavior is to start with the system setting until the user changes it within the app, then remember that state within that application.
The extended quote and dash characters are always accessible using option-key combinations, so if you're always going to disable the option, I'd prefer it were simply not there at all. (i.e., always disable "smart" quotes, dashes, links, etc., maybe the whole extended menu — fonts and colors don't make any sense in a commit message either.)
Still, that's a "wish", not a requirement. Functionally, this change is sufficient (and solves a huge source of frustration for me!). I'm just concerned that the user experience will still be confusing. Thanks! (Hoping 1.8.1 comes out soon!)
Both substitution of dashes and quotes are disabled by default now since this doesn't make sense in a commit. While the user can re-enable them on a per-commit basis we don't remember this (I don't believe this is desired).
This was fixed in some older ST version, I remember. But with the latest it seems to have regressed. My bet is a nib change accidentally reverted. Maybe the true fix should be in code.