Is there any way to have a string literal that is read "raw"

Is there any way to have a string literal that is read "raw"

[Lennart Borgman]

Is it possible to tell Emacs not to interpret escape character in a 
certain string? If I have something like this:

   (setq str "some\thing\escaped")

Can this be changed without changing the literal so that Emacs takes 
exactly what is in the string, without escaping any characters?

Re: Is there any way to have a string literal that is read "raw"

[David Kastrup]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Is it possible to tell Emacs not to interpret escape character in a
> certain string? If I have something like this:
>
>    (setq str "some\thing\escaped")
>
> Can this be changed without changing the literal so that Emacs takes
> exactly what is in the string, without escaping any characters?

What would you need this for?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Is there any way to have a string literal that is read "raw"

[Lennart Borgman]

David Kastrup wrote:

>>Is it possible to tell Emacs not to interpret escape character in a
>>certain string? If I have something like this:
>>
>>   (setq str "some\thing\escaped")
>>
>>Can this be changed without changing the literal so that Emacs takes
>>exactly what is in the string, without escaping any characters?
>>    
>>
>
>What would you need this for?
>  
>
I was thinking of an easier way of handling w32 file names. When trying 
to build with MSYS it fails just because of the file name Emacs got from 
somewhere is in w32 format. It would be more easy if there was a way to 
tell Emacs that "this is just a raw string, please do not escape it".

In fact I think at least building with MSYS then would succeed - and 
that would be nice!

Re: Is there any way to have a string literal that is read "raw"

[David Kastrup]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> David Kastrup wrote:
>
>>>Is it possible to tell Emacs not to interpret escape character in a
>>>certain string? If I have something like this:
>>>
>>>   (setq str "some\thing\escaped")
>>>
>>>Can this be changed without changing the literal so that Emacs takes
>>>exactly what is in the string, without escaping any characters?
>>>    
>>>
>>
>>What would you need this for?
>>  
> I was thinking of an easier way of handling w32 file names. When
> trying to build with MSYS it fails just because of the file name
> Emacs got from somewhere is in w32 format.

What does "got from somewhere" mean?  Could you provide an example?

> It would be more easy if there was a way to tell Emacs that "this is
> just a raw string, please do not escape it".
>
> In fact I think at least building with MSYS then would succeed - and
> that would be nice!

AUCTeX has to deal with strings passed into Emacs via MSYS, too, and
it usually does this with the equivalent of

emacs --eval '(do-something-with (pop command-line-args-left))' "$FILENAME"

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Is there any way to have a string literal that is read "raw"

[Lennart Borgman]

David Kastrup wrote:

>> I was thinking of an easier way of handling w32 file names. When
>>
>>trying to build with MSYS it fails just because of the file name
>>Emacs got from somewhere is in w32 format.
>>    
>>
>
>What does "got from somewhere" mean?  Could you provide an example?
>  
>

Look under why you should avoid MSYS here:

    http://ourcomments.org/Emacs/w32-build-emacs.html#checking-setup

In that example there are paths in MSYS format (ie unix format). However 
you can replace `pwd` with `pwd -W` and get those in w32 format. Then 
you get the problem I am thinking of. But thinking about it again this 
could perhaps be solved (worked around) by writing just a small exe that 
provides path info in Emacs style and compile this in configure.bat? 
Would that be possible?

>emacs --eval '(do-something-with (pop command-line-args-left))' "$FILENAME"
>  
>
The problem is the strings are inside the eval in my example.

Re: Is there any way to have a string literal that is read "raw"

[David Kastrup]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> In that example there are paths in MSYS format (ie unix
> format). However you can replace `pwd` with `pwd -W` and get those in
> w32 format. Then you get the problem I am thinking of. But thinking
> about it again this could perhaps be solved (worked around) by writing
> just a small exe that provides path info in Emacs style and compile
> this in configure.bat? Would that be possible?
>
>>emacs --eval '(do-something-with (pop command-line-args-left))' "$FILENAME"
>>  
>>
> The problem is the strings are inside the eval in my example.

Well, then move them out.  That's the whole point of the above
construct: getting a string _verbatim_ from the environment without
any interpretation of quotes or backslashes or similar.  The above has
not been written as

emacs --eval "(do-something-with \"$FILENAME\")"

for good reason.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Is there any way to have a string literal that is read "raw"

[Lennart Borgman]

I was wrong about MSYS "pwd -W". It actually gives the output in Emacs 
w32 style. I can not remember what happened now then. I will have to try 
again. Coming back.

Re: Is there any way to have a string literal that is read "raw"

[Richard M. Stallman]

    Is it possible to tell Emacs not to interpret escape character in a 
    certain string? If I have something like this:

       (setq str "some\thing\escaped")

    Can this be changed without changing the literal so that Emacs takes 
    exactly what is in the string, without escaping any characters?

I would not dream of changing something as fundamental as string
syntax for something as specific as filename handling, even if it were
meant to be used on the GNU system.  And since it is merely for the
sake of Windows, an unethical system that we aim to replace, the
motive is even further from sufficient.

Nothing important in the design of Emacs should be designed for the
sake of Windows, because that would be giving Windows influence it
should not have.

Re: Is there any way to have a string literal that is read "raw"

[Lennart Borgman]

Richard M. Stallman wrote:

>I would not dream of changing something as fundamental as string
>syntax for something as specific as filename handling, even if it were
>meant to be used on the GNU system.  And since it is merely for the
>sake of Windows, an unethical system that we aim to replace, the
>motive is even further from sufficient.
>  
>
Of course not. I just wondered if there were some other method for 
creating lisp objects than (read ..) that I had missed.

>Nothing important in the design of Emacs should be designed for the
>sake of Windows, because that would be giving Windows influence it
>should not have.
>
There are many roads to the goal. How can one be sure which step is the 
best without considering advantages and drawbacks with an open mind?

Re: Is there any way to have a string literal that is read "raw"

[Richard M. Stallman]

    >Nothing important in the design of Emacs should be designed for the
    >sake of Windows, because that would be giving Windows influence it
    >should not have.
    >
    There are many roads to the goal. How can one be sure which step is the 
    best without considering advantages and drawbacks with an open mind?

The question is not whether to be open to consider advantages and
drawbacks.  The question is which of them matter.

What I've told you is that advantages only for Windows users are not
important advantages for the GNU Project.  Our goal is to replace
Windows, not to enhance it, and we must not allow ourselves to be
distracted from this goal for the convenience of Windows users.

Re: Is there any way to have a string literal that is read "raw"

[Lennart Borgman]

Richard M. Stallman wrote:

>    >Nothing important in the design of Emacs should be designed for the
>    >sake of Windows, because that would be giving Windows influence it
>    >should not have.
>    >
>    There are many roads to the goal. How can one be sure which step is the 
>    best without considering advantages and drawbacks with an open mind?
>
>The question is not whether to be open to consider advantages and
>drawbacks.  The question is which of them matter.
>
>What I've told you is that advantages only for Windows users are not
>important advantages for the GNU Project.  Our goal is to replace
>Windows, not to enhance it, and we must not allow ourselves to be
>distracted from this goal for the convenience of Windows users.
>
Yes, I agree to that, but maybe that does not mean that "advantages only 
for Windows users" are unimportant and does not contribute to GNU? For 
example I have found myself spending a lot of time trying to overcome 
different problems I meet in Emacs as a Windows users. There might be 
many possible contributors on Windows that does the same. Would it not 
be an advantage for GNU if we could spend more of our power actually 
contributing to the overall project?

We may perhaps also contribute with our knowledge of Windows. We can 
tell what we think are good on Windows and what we lack in Emacs and 
GNU/Linux. There are plenty of things that I believe could benefit from 
studying Windows solutions. Do you not think that this could speed up 
the development? Is not this a viable strategy?

Re: Is there any way to have a string literal that is read "raw"

[Richard M. Stallman]

    >What I've told you is that advantages only for Windows users are not
    >important advantages for the GNU Project.  Our goal is to replace
    >Windows, not to enhance it, and we must not allow ourselves to be
    >distracted from this goal for the convenience of Windows users.

    Yes, I agree to that, but maybe that does not mean that "advantages only 
    for Windows users" are unimportant and does not contribute to GNU? For 
    example I have found myself spending a lot of time trying to overcome 
    different problems I meet in Emacs as a Windows users. There might be 
    many possible contributors on Windows that does the same. Would it not 
    be an advantage for GNU if we could spend more of our power actually 
    contributing to the overall project?

This is true when the Windows users are making contributions to Emacs
that make Emacs better as a part of the GNU system.  In other words,
contributions that really matter, contributions that are not
Windows-only.

This does not alter the point that Windows-only improvements are not
important for the GNU Project.  Correcting Windows-only bugs or
misfeatures is welcome, just not as important as making Emacs better
on the GNU system.  Windows-only features are not acceptable.

To gain many developers at the cost of forgetting our goal would be
a grave error.

    There are plenty of things that I believe could benefit from 
    studying Windows solutions. Do you not think that this could speed up 
    the development? Is not this a viable strategy?

If you mean, looking at Windows for ideas that we would apply in a
system-independent way, and that could make Emacs better on all
platforms, that is a useful thing to do.  It is useful precisely
because any features that result would not be Windows-only.

However, in order to be desirable, these features would have to
provide advantages on the GNU system, not just on Windows.

Re: Is there any way to have a string literal that is read "raw"

[Lennart Borgman]

Richard M. Stallman wrote:

>This does not alter the point that Windows-only improvements are not
>important for the GNU Project.  Correcting Windows-only bugs or
>misfeatures is welcome, just not as important as making Emacs better
>on the GNU system.  Windows-only features are not acceptable.
>  
>
Why?

This is just a strategic choice and as such I do think it needs an 
explanation. It is not the goal. But even though I say this now I would 
like to leave the discussion until  after the release.

Re: Is there any way to have a string literal that is read "raw"

[Richard M. Stallman]

Windows-only features are unacceptable because their focus is to make
the use of Windows more convenient, and that does not contribute to
the goal of freedom.  We want to replace Windows and other non-free
software with free software.  Work that only makes Windows easier to
use is working against our goal.

If a program would run only on Windows, we recommend that people not
write that program at all.  If we were to distribute such a program,
that would put us in a hypocritical position.  So we don't distribute
such programs, and we hope you won't write them.

Re: Is there any way to have a string literal that is read "raw"

[Eli Zaretskii]

> From: "Richard M. Stallman" <rms@gnu.org>
> Date: Mon, 11 Jul 2005 12:54:12 -0400
> Cc: emacs-devel@gnu.org
> 
> If a program would run only on Windows, we recommend that people not
> write that program at all.  If we were to distribute such a program,
> that would put us in a hypocritical position.  So we don't distribute
> such programs

Actually, we (i.e. the FSF and the GNU Project) do.  When I worked on
the GNU Software for MS-Windows and MS-DOS CDROM, you agreed to put 3
programs there that were written specifically for the users of
Windows: the installer of the software, a clone of the Unix `man'
command, and DJTAR, a utility that unpacks .tar.gz archives.

I think the principle was: if the Windows-specific program helps
people use GNU software, it is okay to write and distribute it.  For
the same reason, there are several Windows-specific programs that we
maintain and distribute with Emacs (addpm, cmdproxy, ddeclient, etc.).

So I think the ``Windows-specific equals BAD'' principle is too
stringent; one needs instead to argue that the specific program or
feature in question does not help the Free Software cause in any
significant way.  And whether this is true in the case in point is
very hard to establish unequivocally, and thus open to opinions.

Re: Is there any way to have a string literal that is read "raw"

[Richard M. Stallman]

    > If a program would run only on Windows, we recommend that people not
    > write that program at all.  If we were to distribute such a program,
    > that would put us in a hypocritical position.  So we don't distribute
    > such programs

    Actually, we (i.e. the FSF and the GNU Project) do.  When I worked on
    the GNU Software for MS-Windows and MS-DOS CDROM, you agreed to put 3
    programs there that were written specifically for the users of
    Windows: the installer of the software, a clone of the Unix `man'
    command, and DJTAR, a utility that unpacks .tar.gz archives.

I stand corrected on this detail, but the facts that you've cited
agree with the general principle that I stated.

    I think the principle was: if the Windows-specific program helps
    people use GNU software, it is okay to write and distribute it.  For
    the same reason, there are several Windows-specific programs that we
    maintain and distribute with Emacs (addpm, cmdproxy, ddeclient, etc.).

These programs are best understood as part of porting Emacs to
Windows, making the standard Emacs functionality work there too.
Porting Emacs is something we support, whether the code is inside
Emacs or in a separate auxiliary program.

The crucial distinction is between porting Emacs so that its standard
functionality works on Windows, and extending Emacs with new
functionality that only works on Windows.  The latter is what we don't
do.  Extensions to Emacs must be done in a way that runs on the GNU
system.

Re: Is there any way to have a string literal that is read "raw"

[Sean O'Rourke]

"Richard M. Stallman" <rms@gnu.org> writes:
> I would not dream of changing something as fundamental as string
> syntax for something as specific as filename handling, even if it were
> meant to be used on the GNU system.

Some sort of literal string syntax would also be very useful for
regular expressions, since the Emacs syntax tends to be
backslash-heavy.  I'm sure it has been discussed before, but a quick
Google search didn't turn up anything in the emacs-devel archives.

/s

Re: Is there any way to have a string literal that is read "raw"

[Richard M. Stallman]

    Some sort of literal string syntax would also be very useful for
    regular expressions, since the Emacs syntax tends to be
    backslash-heavy.

In theory we could install such a syntax as an alternative.  However,
the need to be able to parse sexps both forward and backward (in
forward-sexp, etc.) could make it difficult to design such a syntax
that would really fit in Emacs.

Re: Is there any way to have a string literal that is read "raw"

[Markus Gritsch]

Richard M. Stallman wrote:
>     Is it possible to tell Emacs not to interpret escape character in a 
>     certain string? If I have something like this:
> 
>        (setq str "some\thing\escaped")
> 
>     Can this be changed without changing the literal so that Emacs takes 
>     exactly what is in the string, without escaping any characters?
> 
> I would not dream of changing something as fundamental as string
> syntax for something as specific as filename handling, even if it were
> meant to be used on the GNU system.  And since it is merely for the
> sake of Windows, an unethical system that we aim to replace, the
> motive is even further from sufficient.
> 
> Nothing important in the design of Emacs should be designed for the
> sake of Windows, because that would be giving Windows influence it
> should not have.

I think the intention of the question was not solely bound to support 
Windows path names, and steering the topic into the direction of how 
evil this OS is does certainly not lead to a solution.

As Sean pointed out, it would also be convenient in such cases like 
Regexps handling.

Python for example has beside of the normal string also a notation for a 
raw string:

   regex = r'^.*\n'

Kind regards,
Markus

Re: Is there any way to have a string literal that is read "raw"

[David Kastrup]

Markus Gritsch <gritsch@iue.tuwien.ac.at> writes:

> As Sean pointed out, it would also be convenient in such cases like
> Regexps handling.
>
> Python for example has beside of the normal string also a notation for
> a raw string:
>
>    regex = r'^.*\n'

Which still needs a delimiter, and you used \n which is _not_ regexp
syntax.  Now

     regex = 4H^.*
     

(notice the literal newline) would be retro-chic.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Is there any way to have a string literal that is read "raw"

[Lennart Borgman]

David Kastrup wrote:

>Markus Gritsch <gritsch@iue.tuwien.ac.at> writes:
>
>  
>
>>As Sean pointed out, it would also be convenient in such cases like
>>Regexps handling.
>>
>>Python for example has beside of the normal string also a notation for
>>a raw string:
>>
>>   regex = r'^.*\n'
>>    
>>
>
>Which still needs a delimiter, and you used \n which is _not_ regexp
>syntax.  Now
>
>     regex = 4H^.*
>     
>
>(notice the literal newline) would be retro-chic.
>  
>
You still need escaping, or course, but only for the delimeter.

Re: Is there any way to have a string literal that is read "raw"

[David Kastrup]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> David Kastrup wrote:
>
>>Markus Gritsch <gritsch@iue.tuwien.ac.at> writes:
>>
>>  
>>
>>>As Sean pointed out, it would also be convenient in such cases like
>>>Regexps handling.
>>>
>>>Python for example has beside of the normal string also a notation for
>>>a raw string:
>>>
>>>   regex = r'^.*\n'
>>>    
>>>
>>
>>Which still needs a delimiter, and you used \n which is _not_ regexp
>>syntax.  Now
>>
>>     regex = 4H^.*
>>     
>>
>>(notice the literal newline) would be retro-chic.
>>  
> You still need escaping, or course, but only for the delimeter.

No.  There is no escaping whatsoever, nor is there a delimiter.  The 4
before the H is a character count.  And H stands for "Hollerith code",
the punch card predecessor of "ASCII code".

Looks like you are not oldtimer enough to belong to the
retro-chiqueria.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Is there any way to have a string literal that is read "raw"

[Richard M. Stallman]

    No.  There is no escaping whatsoever, nor is there a delimiter.  The 4
    before the H is a character count.  And H stands for "Hollerith code",
    the punch card predecessor of "ASCII code".

Another advantage of 4H^.*\n is that you can join the 4H club.

However, it won't fit in Emacs Lisp, because it can't be parsed
backwards.

Re: Is there any way to have a string literal that is read "raw"

[Sean O'Rourke]

"Richard M. Stallman" <rms@gnu.org> writes:

>     No.  There is no escaping whatsoever, nor is there a delimiter.  The 4
>     before the H is a character count.  And H stands for "Hollerith code",
>     the punch card predecessor of "ASCII code".
>
> Another advantage of 4H^.*\n is that you can join the 4H club.
>
> However, it won't fit in Emacs Lisp, because it can't be parsed
> backwards.

Yes, but there are 4HclubH4s for every taste.  Imagine trying to
explain that design decision to someone in 10 years...

/s

Re: Is there any way to have a string literal that is read "raw"

[David Kastrup]

"Sean O'Rourke" <sorourke@cs.ucsd.edu> writes:

> "Richard M. Stallman" <rms@gnu.org> writes:
>
>>     No.  There is no escaping whatsoever, nor is there a delimiter.  The 4
>>     before the H is a character count.  And H stands for "Hollerith code",
>>     the punch card predecessor of "ASCII code".
>>
>> Another advantage of 4H^.*\n is that you can join the 4H club.
>>
>> However, it won't fit in Emacs Lisp, because it can't be parsed
>> backwards.
>
> Yes, but there are 4HclubH4s for every taste.  Imagine trying to
> explain that design decision to someone in 10 years...

I don't think that font-lock patterns can be made to deal with that
currently, so this is definitely not stuff we should be considering
for the next release.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Is there any way to have a string literal that is read "raw"

[Richard M. Stallman]

    > However, it won't fit in Emacs Lisp, because it can't be parsed
    > backwards.

    Yes, but there are 4HclubH4s for every taste.

Alas, that won't help, because symbols can end in `H4'.

						   Imagine trying to
    explain that design decision to someone in 10 years...

Since I made that design decision 20 years ago, why would 10 more
years make it hard to explain?