Turns out that bash's regexps (using `=~') changed so that quoting them
matches a literal string, and it seems dangerous to rely on parsing
unquoted regexps. One way around this is to put the regexp in a
variable, but for the two simple uses that this script had, it's easy to
avoid regexps completely.
redex patterns a bunch:
- repeats are turned into wrappers in sequences,
- names are all explicit,
- non-terminals are wrapped with `nt',
- cross patterns always have the hyphens in them.
- ellipses names are normalized (so there are no "hidden"
name equalities); this also means that repeat patterns
can have both a regular name and a mismatch name
Also, added a match-a-pattern helper macro that checks to make sure
that functions that process patterns don't miss any cases
to be a hierarchical-list-item<%> object, but now it is
a list of language names (same information, different data)
and one place didn't get updated.
Closes PR 12462
the purpose of drawing arrows.
The computation to fill in the cache seems to actually be pretty quick and
the work to clear the cache when it is out of date (via a call to on-change)
can be substantial on big files, so just not maintaining the cache seems better.
(there are 7254 arrows in drracket/private/unit.rkt, stored in an interval map,
and iterating over the interval-map in a for loop seems to be time consuming)
Also, DrRacket could get into a state where switching tabs would trigger a
call to on-change, which means that switching tabs would take a few seconds.
Using the old extension protocol for MysterX --- plus the hack of
a dummy source module for a kind of portability --- really should
be replaced with an FFI-based approach to the MysterX DLL.
* In base64 encoding remove all newlines from the encoded result, avoids
getting an invalid result.
* In qp encoding:
- replace all spaces by underlines, not just the first (looks like a
typo in the previous code)
- encode "?"s and "_"s too, as required for this encoding
- remove soft newlines (again, avoid an invalid result)
* Use `regexp-replace*' to encode the parts between the lines. Besides
making the code simpler, it fixes a bug in the previous code where
multiple lines would each get encoded and the results concatenated
without the newlines or any other whitespace.
* When the string to be encoded is longer than 70 characters, split and
encode the sub-parts, then concatenate the encodings with a "\n "
separator. This is done as a poor attempt to follow the line length
limits specified in rfc2047, or more concretely, to avoid sendmail's
"!\n " splitting.
* Use `re:non-ascii' to look for a non-ascii character => faster.
* Use either CR or LF for a newline, not just LF.
* Use `regexp-replace*' to encode the parts between the lines. Besides
making the code simpler, it fixes a bug in the previous code where
multiple lines would each get encoded and the results concatenated
without the newlines or any other whitespace.
There might be existing uses of `net/sendmail' that did this quoting
since this code didn't do so. Such uses would continue to work fine,
since quoted strings would already be plain ASCII, so a second quoting
would leave it as is.
Note that the quoted strings are also used as command line arguments.
It seems that sendmail deals with these all fine when they appear as
command line arguments. This means that any valid email address format
can be used, not just "raw" emails. If there are some sendmails that
don't do this, then it would be better to add a `-t' flag to let
sendmail parse the text in the message.
One caveat (not a new one): since they're passed as is, it is possible
to use two emails in a single string, as in "a@b.com, c@d.com". This
could lead to obvious problems if someone uses "Bar, Foo <foo@bar.org>"
instead of "\"Bar, Foo\" <foo@bar.org>". (Using a `-t' to parse the
content won't help with that...) The only way to avoid this would be to
parse the emails and quote the name part if needed. But that's a much
hairier piece of code.
* Move the `X-Mailer' header to the top, so that the interesting headers
are all together at the bottom (the top gets littered by server
headers anyway).
* Use `subprocess' directly (`process*' wasn't really doing anything
more than that).
* Allow the sender to be `#f', leaving the header out. This makes all
sendmails that I've used use the username that is running the process.
* Just search for a sendmail program: don't barf on windows, so it can
be used in case there is a sendmail.exe executable there.
* Remove `no-mail-recipients' to make it in-line with other racket code
that doesn't raise super-specific exceptions.
* Use port counting instead of doing the counts manually, much simpler
code.
