bug#6390: Should not regexp-quote quote newline?

[MON KEY]

On Sat, Jun 12, 2010 at 9:28 AM, Lennart Borgman
<lennart.borgman@gmail.com> 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 <STAR>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 <FEATURE-X> .*?"


--
/s_P\