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

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

[Lennart Borgman]

To illustrate the problem eval this

(progn
  (setq x (regexp-quote "a
b"))
  (message "length x=%d" (length x)))

The length of x will be 3 because the string returned by regexp-quote
includes a newline.

Would it not be more practical if the result was "a\nb"?

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

[Andreas Schwab]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> Would it not be more practical if the result was "a\nb"?

That's exactly what you get.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Lennart Borgman]

On Thu, Jun 10, 2010 at 5:01 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> Would it not be more practical if the result was "a\nb"?
>
> That's exactly what you get.

;-)

"a\\nb"

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

[Drew Adams]

> >> Would it not be more practical if the result was "a\nb"?
> > That's exactly what you get.
> "a\\nb"

A newline char is not a regexp special char.
Is that what you were thinking?
You are not being very clear, at least to me.

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

[Andreas Schwab]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Thu, Jun 10, 2010 at 5:01 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>
>>> Would it not be more practical if the result was "a\nb"?
>>
>> That's exactly what you get.
>
> ;-)
>
> "a\\nb"

This is a totally different regexp.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Lennart Borgman]

On Thu, Jun 10, 2010 at 6:08 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> On Thu, Jun 10, 2010 at 5:01 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>>> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>>
>>>> Would it not be more practical if the result was "a\nb"?
>>>
>>> That's exactly what you get.
>>
>> ;-)
>>
>> "a\\nb"
>
> This is a totally different regexp.

;-)

Depends on how u "read" it.

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

[Andreas Schwab]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Thu, Jun 10, 2010 at 6:08 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>
>>> On Thu, Jun 10, 2010 at 5:01 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>>>> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>>>
>>>>> Would it not be more practical if the result was "a\nb"?
>>>>
>>>> That's exactly what you get.
>>>
>>> ;-)
>>>
>>> "a\\nb"
>>
>> This is a totally different regexp.
>
> ;-)
>
> Depends on how u "read" it.

If you want a print representation then use print.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Lennart Borgman]

On Thu, Jun 10, 2010 at 6:22 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>>>>> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>>>>
>>>>>> Would it not be more practical if the result was "a\nb"?
>>>>>
>>>>> That's exactly what you get.
>>>>
>>>> ;-)
>>>>
>>>> "a\\nb"
>>>
>>> This is a totally different regexp.
>>
>> ;-)
>>
>> Depends on how u "read" it.
>
> If you want a print representation then use print.


Thanks, but that does not apply to the situation I am talking about.

But since misunderstandings are great here I might clarify the
situation: I am thinking about situations where you want to edit a
regexp. One such situation is for example editing the isearch regexp.

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

[Andreas Schwab]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> Thanks, but that does not apply to the situation I am talking about.

No, it is exactly what you want.

> But since misunderstandings are great here I might clarify the
> situation: I am thinking about situations where you want to edit a
> regexp. One such situation is for example editing the isearch regexp.

You want to edit a (kind of) print representation of a string, not a
quoted regexp (the only purpose of which is to create a regexp that
matches exactly a given string).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Lennart Borgman]

On Thu, Jun 10, 2010 at 7:03 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> Thanks, but that does not apply to the situation I am talking about.
>
> No, it is exactly what you want.


Yes, you are right. Something like this seems to do what I want:

(defun my-quote-string (str)
  "Return string STR quoted like `prin1' do it."
  (let ((ret (prin1-to-string str)))
    (substring ret 1 -1)))


>> But since misunderstandings are great here I might clarify the
>> situation: I am thinking about situations where you want to edit a
>> regexp. One such situation is for example editing the isearch regexp.
>
> You want to edit a (kind of) print representation of a string, not a
> quoted regexp (the only purpose of which is to create a regexp that
> matches exactly a given string).


Yes, I agree now. It is better to keep it conceptually separated like
that. However I then miss the function above.

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

[Lennart Borgman]

On Thu, Jun 10, 2010 at 8:07 PM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> On Thu, Jun 10, 2010 at 7:03 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>
>>> Thanks, but that does not apply to the situation I am talking about.
>>
>> No, it is exactly what you want.
>
>
> Yes, you are right. Something like this seems to do what I want:
>
> (defun my-quote-string (str)
>  "Return string STR quoted like `prin1' do it."
>  (let ((ret (prin1-to-string str)))
>    (substring ret 1 -1)))

For the record here is a better version

(defun reb-quote-string (str)
 "Return string STR quoted like `prin1' do it."
 (let* ((print-escape-newlines t)
        (ret (prin1-to-string str)))
   (substring ret 1 -1)))

Something changed print-escape-newlines somewhere ...

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

[Lennart Borgman]

On Fri, Jun 11, 2010 at 1:11 AM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> On Thu, Jun 10, 2010 at 8:07 PM, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>> On Thu, Jun 10, 2010 at 7:03 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>>> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>>
>>>> Thanks, but that does not apply to the situation I am talking about.
>>>
>>> No, it is exactly what you want.
>>
>>
>> Yes, you are right. Something like this seems to do what I want:
>>
>> (defun my-quote-string (str)
>>  "Return string STR quoted like `prin1' do it."
>>  (let ((ret (prin1-to-string str)))
>>    (substring ret 1 -1)))
>
> For the record here is a better version
>
> (defun reb-quote-string (str)
>  "Return string STR quoted like `prin1' do it."
>  (let* ((print-escape-newlines t)
>        (ret (prin1-to-string str)))
>   (substring ret 1 -1)))
>
> Something changed print-escape-newlines somewhere ...

Unfortunately print-escape-newlines does not quote tab, only newline
and form-feed. Which in my opinion is a bug. To fix this just copy 5
lines in print.c at line 1667 and replace form-feed with tab. (I have
just done that in my patched copy, but it is easier to do this by hand
then to use a patch.)

Is there any objections to this change?

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

[Drew Adams]

> (setq x (regexp-quote "a
> b"))
> (message "length x=%d" (length x))
> 
> The length of x will be 3 because the string returned
> by regexp-quote includes a newline.
> Would it not be more practical if the result was "a\nb"?

I, for one, do not understand you.

(setq y "a
b")
(setq x (regexp-quote y))
(setq z "a\nb")
(equal x y) = (equal x z) = t
(length x) = (length z) = 3

What are you trying to say?
And what does it mean to "quote newline"?

Please try to explain clearly what the problem is that you see, or what you are
trying to do that does not succeed as you expect.

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

[Lennart Borgman]

On Thu, Jun 10, 2010 at 5:22 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> (setq x (regexp-quote "a
>> b"))
>> (message "length x=%d" (length x))
>>
>> The length of x will be 3 because the string returned
>> by regexp-quote includes a newline.
>> Would it not be more practical if the result was "a\nb"?
>
> I, for one, do not understand you.

Yes, I saw that Andreas probably did not get either what I wanted to say.

I checked the length because looking at x is a bit frustrating because
of the translations between newline <-> \n that might occur.

> (setq y "a
> b")
> (setq x (regexp-quote y))
> (setq z "a\nb")
> (equal x y) = (equal x z) = t
> (length x) = (length z) = 3
>
> What are you trying to say?

That the regexp-quoted string includes the new line character instead
of the two chararcers \n.

The latter is more practical in many situations since this is a regexp.

> And what does it mean to "quote newline"?

Replacing newline char with \n.

You can of course do that yourself, but I really see no reason why
regexp-quote should not do it. (Yes, the regexp works just as well
with newline in it as the two chars \n in it.)

Perhaps people wants it this way, but then I would suggest that the
doc strings tells about the current behaviour.

Maybe there should be a function `string-quote' that does replacements
of newline => \n etc?


> Please try to explain clearly what the problem is that you see, or what you are
> trying to do that does not succeed as you expect.
>
>

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

[Juanma Barranquero]

On Thu, Jun 10, 2010 at 17:34, Lennart Borgman
<lennart.borgman@gmail.com> wrote:

> Perhaps people wants it this way, but then I would suggest that the
> doc strings tells about the current behaviour.

Do you want the docstring for regexp-quote to list every single
character that it does not quote because they aren't special in
regexps? That's gonna be a long long list.

    Juanma

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

[Lennart Borgman]

On Thu, Jun 10, 2010 at 6:28 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Thu, Jun 10, 2010 at 17:34, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>
>> Perhaps people wants it this way, but then I would suggest that the
>> doc strings tells about the current behaviour.
>
> Do you want the docstring for regexp-quote to list every single
> character that it does not quote because they aren't special in
> regexps? That's gonna be a long long list.

Not necessarily ... ;-)

I thinking about those that are normally quoted in strings.

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

[Andreas Schwab]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> That the regexp-quoted string includes the new line character instead
> of the two chararcers \n.

How does that fit into the purpose of regexp-quote?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Lennart Borgman]

On Thu, Jun 10, 2010 at 6:56 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> That the regexp-quoted string includes the new line character instead
>> of the two chararcers \n.
>
> How does that fit into the purpose of regexp-quote?

Yes, that is a good question. That is why I said I am not sure and
maybe there should be another function to do that backslash quoting I
am asking for.

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

[MON KEY]

> Unfortunately print-escape-newlines does not quote tab, only newline
> and form-feed.

This is not at all unfortunate.

> Which in my opinion is a bug.

Which would make you wrong.

(describe-variable 'print-escape-newlines)
,----
| Non-nil means print newlines in strings as `\n'.
| Also print formfeeds as `\f'.
`----

Where is \t mentioned?

> Is there any objections to this change?

Sure. I object on the grounds that what you propose is madness.

But, if others do agree with the proposed changed may I suggest then
that we also replace newline with SPACE that way we needn't needlessly
concern ourselves with vertical motion in general...


--
/s_P\

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

[Lennart Borgman]

On Fri, Jun 11, 2010 at 6:19 AM, MON KEY <monkey@sandpframing.com> wrote:
>> Unfortunately print-escape-newlines does not quote tab, only newline
>> and form-feed.
>
>> Is there any objections to this change?
>
> Sure. I object on the grounds that what you propose is madness.

I can see no objection at all. What is it?

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

[MON KEY]

On Fri, Jun 11, 2010 at 12:43 AM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
>> Sure. I object on the grounds that what you propose is madness.
>
> I can see no objection at all. What is it?
>

You've confirmed my suspicion ;)

The objection is that what you propose is madness, i.e lunacy!

It is absolutely NTRT to interpolate any such chars routed through the
elisp printer simply b/c you disagree with how an ASCII standard
character has been historically (mis)interpreted. Its the _users_
prerogative to dictate her intention here; it certainly isn't yours,
or Microsofts', or Emacs'.

IMHO it would be _insane_ to replace "\f" linefeed with "\t"

Evaluate these to see why:

 (progn
   (insert-char 12 1)
   (describe-char (1- (point))))

 (progn
   (insert-char 9 1)
   (describe-char (1- (point))))

Among other things, you may notice the inserted glyph `^L' which is used
throughout Emacs as the default value for indication of page boundaries.
e.g. `page-delimiter' and her buddy `forward-page'...

Not only are you asking to have the form-feed value replaced with an entirely
different _non-visible_ character but you are asking to fundamentally alter the
semantics from:
 "Occurences of this character indicate vertical movement of the
print-head at EOL"
to:
 "Occurences of this character indicate tabbed horizontal movement at EOL"

Blech! Why would you want to do something so silly?

Check out this history of the form-feed and (one of) its early
intended applications:

:SEE (URL `http://www.rfc-editor.org/EOLstory.txt')

:SEE-ALSO (URL `http://en.wikipedia.org/wiki/Linefeed')

P.S. I've taken on faith that you aren't instead suggesting to replace
"\f" with the line tabulation char `^K' ASCII 11 e.g. (insert 11)
Which would make only slightly more sense than the folly you've proposed.

--
/s_P\

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

[Lennart Borgman]

On Fri, Jun 11, 2010 at 10:09 PM, MON KEY <monkey@sandpframing.com> wrote:
> On Fri, Jun 11, 2010 at 12:43 AM, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>>> Sure. I object on the grounds that what you propose is madness.
>>
>> I can see no objection at all. What is it?
>>
>
> You've confirmed my suspicion ;)
>
> The objection is that what you propose is madness, i.e lunacy!


I still see no objection because I have not the slightest idea how you
mean all the things you are telling are related to my proposal.

The only interpretation I can make is that the madness is already here
since linefeed and form-feed already may be written as \n and \f if
you set print-escape-newlines to t. All I proposed was that it should
write tab as \t too.

I might not have proposed that if I knew it was that utterly
disturbing to someone. ;-)

On a brighter side I think you have misunderstood my question and
suggestion. Please read it again and especially the conversation with
Andreas.



> It is absolutely NTRT to interpolate any such chars routed through the
> elisp printer simply b/c you disagree with how an ASCII standard
> character has been historically (mis)interpreted. Its the _users_
> prerogative to dictate her intention here; it certainly isn't yours,
> or Microsofts', or Emacs'.
>
> IMHO it would be _insane_ to replace "\f" linefeed with "\t"
>
> Evaluate these to see why:
>
>  (progn
>   (insert-char 12 1)
>   (describe-char (1- (point))))
>
>  (progn
>   (insert-char 9 1)
>   (describe-char (1- (point))))
>
> Among other things, you may notice the inserted glyph `^L' which is used
> throughout Emacs as the default value for indication of page boundaries.
> e.g. `page-delimiter' and her buddy `forward-page'...
>
> Not only are you asking to have the form-feed value replaced with an entirely
> different _non-visible_ character but you are asking to fundamentally alter the
> semantics from:
>  "Occurences of this character indicate vertical movement of the
> print-head at EOL"
> to:
>  "Occurences of this character indicate tabbed horizontal movement at EOL"
>
> Blech! Why would you want to do something so silly?
>
> Check out this history of the form-feed and (one of) its early
> intended applications:
>
> :SEE (URL `http://www.rfc-editor.org/EOLstory.txt')
>
> :SEE-ALSO (URL `http://en.wikipedia.org/wiki/Linefeed')
>
> P.S. I've taken on faith that you aren't instead suggesting to replace
> "\f" with the line tabulation char `^K' ASCII 11 e.g. (insert 11)
> Which would make only slightly more sense than the folly you've proposed.
>
> --
> /s_P\
>

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

[MON KEY]

On Fri, Jun 11, 2010 at 4:37 PM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> All I proposed was that it should write tab as \t too.

 i) This is not the extent of what you proposed;
ii) It is none-the-less a bad idea;

Newline and formfeed are control characters which affect the display
and interpretation of vertical character motion and display. Tab OTOH
is horizontal whitespace and doesn't affect vertical display in the
same manner (either syntactically or visually).

Regardless, the function name `print-escape-newlines' and its
documentation SAY NOTHING ABOUT ESCAPING TAB CHARACTERS!!!!!

What you really want is `print-escape-arbitrarily-for-lennart' :P
You can implement such a feature by cobbling together various
bits of code from format-spec.el format.el descr-text.el pp.el and
`filter-buffer-substring'.

> On a brighter side I think you have misunderstood my question and
> suggestion.

I well understood your suggestion as presented:

,----
| Unfortunately print-escape-newlines does not quote tab, only newline
| and form-feed. Which in my opinion is a bug. To fix this just copy 5
| lines in print.c at line 1667 and replace form-feed with tab. (I have
| just done that in my patched copy, but it is easier to do this by hand
| then to use a patch.)
`----

If you want your suggestions to be understood by others with as little
ambiguity as possible you _must_ submit patches or example code.

As written I read your 'suggestion' to say:

 "... replace form-feed with tab ..."

In the absence of a patch/example how else could/should it have been
read? FWIW I _did_ take time to examine lines ~1667 of print.c and it
certainly wasn't clear to me what you intended.

Thanks for wasting my time twice. Once in attempting to understand
what you meant and now a second time to clarify a mutual
misunderstanding.

Multiply this type of waste by the number of people (now and in the
future) whom reference this bug report and you've potentially wasted
alot of people's time.

> I might not have proposed that if I knew it was that utterly
> disturbing to someone. ;-)

I doubt that.

You seem all too ready to file ambiguous bug reports without
backtraces and/or to suggest changes/fixes to vacuous `bugs' without
an accompanying patch or example source which is illustrative of both
a problem and of a proposed solution.

Indeed, I do find this utterly disturbing on your part (esp. in the
aggregate).

--
/s_P\

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

[Lennart Borgman]

On Sat, Jun 12, 2010 at 8:18 AM, MON KEY <monkey@sandpframing.com> wrote:
> On Fri, Jun 11, 2010 at 4:37 PM, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>> All I proposed was that it should write tab as \t too.
>
>  i) This is not the extent of what you proposed;

I guess you mean "this is not what I thought you proposed".

> 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. And it is
variable, not a function

  print-escape-newlines is a variable defined in `C source code'.
  Its value is nil

  Documentation:
  Non-nil means print newlines in strings as `\n'.
  Also print formfeeds as `\f'.

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.

I think that is very useful some times, but I can't think of a single
reason why it should not be good to handel TAB the same way in those
cases. Can you? Don't you think getting a printed representation of
this kind is useful.


To clarify things I pointed to what Andreas wrote. The most important
part of that is that the printed representation and the string are
different things. 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.

Is not this what you have been trying to say?



> ,----
> | Unfortunately print-escape-newlines does not quote tab, only newline
> | and form-feed. Which in my opinion is a bug. To fix this just copy 5
> | lines in print.c at line 1667 and replace form-feed with tab. (I have
> | just done that in my patched copy, but it is easier to do this by hand
> | then to use a patch.)
> `----
>
> If you want your suggestions to be understood by others with as little
> ambiguity as possible you _must_ submit patches or example code.
>
> As written I read your 'suggestion' to say:
>
>  "... replace form-feed with tab ..."


Hm, sorry, I could not imagine that ... ;-)


> In the absence of a patch/example how else could/should it have been
> read? FWIW I _did_ take time to examine lines ~1667 of print.c and it
> certainly wasn't clear to me what you intended.
>
> Thanks for wasting my time twice. Once in attempting to understand
> what you meant and now a second time to clarify a mutual
> misunderstanding.


Sorry. But thanks for clarifying this.


> Multiply this type of waste by the number of people (now and in the
> future) whom reference this bug report and you've potentially wasted
> alot of people's time.


Maybe. Or it has clarified a few things for many people.


>> I might not have proposed that if I knew it was that utterly
>> disturbing to someone. ;-)
>
> I doubt that.


;-)


> You seem all too ready to file ambiguous bug reports without
> backtraces and/or to suggest changes/fixes to vacuous `bugs' without
> an accompanying patch or example source which is illustrative of both
> a problem and of a proposed solution.


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. Mail me privately if you want to.


> Indeed, I do find this utterly disturbing on your part (esp. in the
> aggregate).
>
> --
> /s_P\
>

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\

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

[Lennart Borgman]

On Mon, Jun 14, 2010 at 5:00 AM, MON KEY <monkey@sandpframing.com> wrote:
> 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.


So you think you understood what I proposed better than me? That is
very strange.


>>> 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.


Why do you print-escape-newlines is a good name for something that
controls both escaping of newlines and form-feeds?


>> 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.


Thanks, but no.


> 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.


Using the same character for read escapes and regexp backslash makes
things difficult, yes.

And lead to confusing discussions like this one.


>> 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?


It seemed important to you so I thought you might want to tell.


>> 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.


I would be glad if you gave some arguments.


>> 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...


Please don't waste our time! If you have something to say then do it!


> 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.


I think it would be better if you asked me if you do not understand
them. There is no reason wasting other peoples time too. Mail me
privately.


> 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> .*?"


I am sorry, but you are misunderstanding. We also use the bug database
for wishes and suggestions so they do not get lost.

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

[Kevin Rodgers]

Lennart Borgman wrote:
...
> The only interpretation I can make is that the madness is already here
> since linefeed and form-feed already may be written as \n and \f if
> you set print-escape-newlines to t. All I proposed was that it should
> write tab as \t too.

Perhaps there should be a separate variable to print escape sequences for all
the ASCII control characters (see the Basic Char Syntax node of the Emacs Lisp
manual):

\a, \b, \t, \n, \v, \f, \r, \e, \d

It would probably be controversial to include \s and \\ , since they aren't
control characters.

> I might not have proposed that if I knew it was that utterly
> disturbing to someone. ;-)

Perhaps MON KEY objects to backwards-incompatibility.

-- 
Kevin Rodgers
Denver, Colorado, USA

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

[Lennart Borgman]

On Sat, Jun 12, 2010 at 8:51 AM, Kevin Rodgers
<kevin.d.rodgers@gmail.com> wrote:
> Lennart Borgman wrote:
> ...
>>
>> The only interpretation I can make is that the madness is already here
>> since linefeed and form-feed already may be written as \n and \f if
>> you set print-escape-newlines to t. All I proposed was that it should
>> write tab as \t too.
>
> Perhaps there should be a separate variable to print escape sequences for
> all
> the ASCII control characters (see the Basic Char Syntax node of the Emacs
> Lisp
> manual):
>
> \a, \b, \t, \n, \v, \f, \r, \e, \d
>
> It would probably be controversial to include \s and \\ , since they aren't
> control characters.


Maybe the variable should be a list of the ASCII control chars that
the print string function should translate to \t etc?


>> I might not have proposed that if I knew it was that utterly
>> disturbing to someone. ;-)
>
> Perhaps MON KEY objects to backwards-incompatibility.


Yes, I think it was a misunderstanding. And I guess the reason was my
bad proposal in the start of this where I did not distinguish between
the printed string and the actual string. So I guess it is my fault.
(I actually rather confused the regexp syntax with the printed string
syntax, of course.)

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

[Glenn Morris]

I don't see a need to keep open this particular report, which was marked
"wontfix" some time ago.

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

[Lennart Borgman]

On Sat, Jul 9, 2011 at 07:30, Glenn Morris <rgm@gnu.org> wrote:
>
> I don't see a need to keep open this particular report, which was marked
> "wontfix" some time ago.

This was a long time ago. I just reread the thread. My initial
proposal was bad which Andreas pointed out.

However the proposal to escape \t along with \n and \f which are
currently escaped still seems valid.