On Jun 22, 2014, at 3:47 PM, Michael Dickens wrote: > I use XQuartz's xterm, which, when used with default settings, locks when one > of those characters comes up. That's one reason I switched the zmq* ports to > use "0" (zero) instead of the null character. I know that this does not > happen in Apple's Terminal.app, and I'm sure there's a setting I can put in > place to have the xterm interpret these correctly. But, since by default the > xterm does not, and I require xterm for my work (to get the display correct), > and I'm guessing the average user doesn't set the xterm to handle these > characters, then I try to keep from using them in my ports for anything that > comes up under search or info. Any other location I think is fine. - MLD
In other words, you wouldn't use it in the description or long_description, which are two places where quotation marks or apostrophes are likely to occur and which I've been in the habit of converting to smart quotes, because they look better and are more typographically correct and also work better with the syntax highlighting rules I'm using in TextWrangler which misinterprets quotation marks in the descriptions as being the beginning of a string. I think that half-heartedly removing a few UTF-8 characters from a few portfiles is not a solution. My preferred solution is to fix MacPorts so that it does not crash, and to figure out how to get users' terminals to display things correctly, perhaps even having MacPorts set this up for them somehow. If that cannot be done, then we should do a mass removal of all non-ASCII characters from all portfiles and change the modeline to state that Portfiles are ASCII, not UTF-8. But I hope we can avoid that, because it seems inconceivable to me that in the year 2014 UTF-8 cannot be reliably used. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
