From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: MON KEY Newsgroups: gmane.emacs.bugs Subject: bug#6390: Should not regexp-quote quote newline? Date: Sun, 13 Jun 2010 23:00:54 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: dough.gmane.org 1276486118 2725 80.91.229.12 (14 Jun 2010 03:28:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 14 Jun 2010 03:28:38 +0000 (UTC) Cc: 6390@debbugs.gnu.org To: Lennart Borgman Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jun 14 05:28:36 2010 connect(): No such file or directory Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OO0Lj-0003CO-Sc for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Jun 2010 05:28:36 +0200 Original-Received: from localhost ([127.0.0.1]:52437 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OO0Lj-0002fh-4L for geb-bug-gnu-emacs@m.gmane.org; Sun, 13 Jun 2010 23:28:35 -0400 Original-Received: from [140.186.70.92] (port=36461 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OO0Lc-0002fb-W3 for bug-gnu-emacs@gnu.org; Sun, 13 Jun 2010 23:28:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OO0Lb-0002bZ-FN for bug-gnu-emacs@gnu.org; Sun, 13 Jun 2010 23:28:28 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53297) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OO0Lb-0002bV-AF for bug-gnu-emacs@gnu.org; Sun, 13 Jun 2010 23:28:27 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1ONzw1-00021j-Lu; Sun, 13 Jun 2010 23:02:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: MON KEY Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Jun 2010 03:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6390 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix Original-Received: via spool by 6390-submit@debbugs.gnu.org id=B6390.12764844647774 (code B ref 6390); Mon, 14 Jun 2010 03:02:01 +0000 Original-Received: (at 6390) by debbugs.gnu.org; 14 Jun 2010 03:01:04 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONzv5-00021L-1a for submit@debbugs.gnu.org; Sun, 13 Jun 2010 23:01:03 -0400 Original-Received: from mail-gw0-f44.google.com ([74.125.83.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONzv3-00020z-KM for 6390@debbugs.gnu.org; Sun, 13 Jun 2010 23:01:02 -0400 Original-Received: by gwj16 with SMTP id 16so2254903gwj.3 for <6390@debbugs.gnu.org>; Sun, 13 Jun 2010 20:00:57 -0700 (PDT) Original-Received: by 10.151.25.16 with SMTP id c16mr5845692ybj.363.1276484455698; Sun, 13 Jun 2010 20:00:55 -0700 (PDT) Original-Received: by 10.151.10.5 with HTTP; Sun, 13 Jun 2010 20:00:54 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: cRXsO6MEBlUG7dahdPUWDbcnSPQ X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sun, 13 Jun 2010 23:02:01 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:37761 Archived-At: On Sat, Jun 12, 2010 at 9:28 AM, Lennart Borgman wrote: > > I guess you mean "this is not what I thought you proposed". I meant what I wrote. > >> Regardless, the function name `print-escape-newlines' and its >> documentation SAY NOTHING ABOUT ESCAPING TAB CHARACTERS!!!!! > > Yes, it is a terribly bad name for the feature it provides. It is reasonably named, it says what it does. Prob. it is only terrible should one want \t escaped as well. > And it is variable, not a function Yes. Of course it is. Sorry. > As I understand it the purpose of it is make all the > print/prin1/format/pp functions make the written representation of a > string easier to handle in certain cases. Understand whatever you want - this isn't what it `print-escape-newlines' _does_. You might find it exceedingly informative and interesting to look over Emacs sources from pre GNU days when coming to grips with the C vagaries inflicted on the Emacs read eval print loop. It recently came as a great surprise to learn that in the past RMS maintained an Emacs which saw `\' as `/'. Google is your friend. Most likely the `print-escape-newlines' function is a bastardized holdover of the d READ-EVAL-PRINT variables and # reader macros from Maclisp days. :SEE (URL `http://maclisp.info/pitmanual/repl.html') :SEE (URL `http://maclisp.info/pitmanual/syntax.html'). Indeed, the transgression upon our poor (e)lisp REPL by the cult of the curly braced are many, and in the absence of a more maleable readtable and reader syntax she has been afforded little with which retaliate against the mighty C, his `\' escape syntax, and the hordes of bastard regexps his syntax has spawned. > but I can't think of a single reason why it should not be good to > handel TAB the same way in those cases. It is a mistake to extend your lack of foresight on other users of this feature. > Can you? Yes, I believe I can. So what? > Don't you think getting a printed representation of this kind is useful. No, it is absolutely not useful for `print-escape-newlines' to do this. Yes, I might find it useful as a dedicated function under another name. Though I don't think it would be difficult to implement if/when needed, and it certainly doesn't need to be piggy-backed onto the existing feature. > To clarify things I pointed to what Andreas wrote. Nonsense. This was your attempt to deflect my objection to one of your ill conceived proposals to another persons objection to yet another of your ill conceived proposals. IOW recursive nonsense... Which FWIW, is my principal objection to this and other such similar bug reports of yours. They often amount to nothing more than veiled feature requests which if presented/exposed/discussed as such would be received poorly. > The most important part of that is that the printed representation > and the string are different things. Of course they are, but this absolutely _not_ the concern here. > The important quality of the printed representation > that I think you care about is that it is understood by the function > `read' and that when `read' parses the printed representation it gives > you back exactly the original string. There is a saying among a certain type of American from the Northeastern U.S.: "You cahn't get theyah from heeah" > Is not this what you have been trying to say? No. I am saying this: It is patently ridiculous to consider adding \t as an escaped char for `print-escape-newlines'. It is a bad idea. It is not the right thing. It is not a bug that \t is not escaped by `print-escape-newlines'. It is, at best, a limitation of C and associated libs utilized to implement the Emacs dialect of lisp. No amount of mucking via C with the elisp REPL in the manner you propose can reliably and reasonably resolve these issues. > Maybe. Or it has clarified a few things for many people. If that is your intention blog it or post it to the Emacswiki's elisp-cookbook. Just don't call it a bug and don't report it as such. > You can't get backtraces in all cases. If you think the bugs are not > there because you do not understand what I mean you can ask for > clarification. One should not, as a matter of course, be required to request clarification on a one or two sentence `bug report' when there is no bug. It is bad form for you to suggest that others accommodate this sort of behavior by you or anyone else. This goes doubly when the sender's subject line of such `bug report's are phrased in the form of a question which routinely match the pattern: "Should not the .*?" -- /s_P\