bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Lennart Borgman
Subject: bug#6390: Should not regexp-quote quote newline?
Date: Sat, 12 Jun 2010 15:28:04 +0200

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]