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: Mon, 14 Jun 2010 07:33:39 +0200

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.





reply via email to

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