Unmentioned "stringify" aspect in docu buffer-substring-no-properties

Unmentioned "stringify" aspect in docu buffer-substring-no-properties

[Andreas Roehler]

Richard Stallman schrieb:
> Would people please check those files for accuracy one more time?
> They are the files listed in FOR-RELEASE with just one name.

> text.texi
IMO:
Unmentioned "stringify" aspect in
`buffer-substring-no-properties'; also concerns
`buffer-substring'

AFAIU there are two different meanings of string, which
are mixed up in naming and function of

`buffer-substring-no-properties':

1) it takes a portion of the buffer, but not necessary
  of a type `string', so `substring' might mislead
  here (nonetheless, would not ask for changing this
  name for compatiblity reasons)

2) it stringifies these portion, changes the type of it

;;; check the following examples in a buffer starting
   with it, in order to have the Start-End-Entries
   set as given

(defun foo ()
 " "
 (interactive "*")
 )

(buffer-substring-no-properties 34 37)"e \""

(setq baz (buffer-substring-no-properties 34 37))

baz"e \""

(stringp baz)t


;;;

or

(defun foo ()
 " "
 (interactive "*")
 )

(buffer-substring-no-properties 1 41)"(defun foo ()
 \" \"
 (interactive \"*\")
"

(setq baz (buffer-substring-no-properties 1 41))"(defun foo ()
 \" \"
 (interactive \"*\")
"

baz"(defun foo ()
 \" \"
 (interactive \"*\")
"

(stringp baz)t

but

(stringp
(defun foo ()
 " "
 (interactive "*")
 )
)nil

It happened to be a discussion in de.comp.editoren,
concerning a stringify function

The (still disputed) result exploits just the
mentioned quality.

(defun region2string (start end)
 "Make a string from the chars of a region.
Doublequotes inside will be quoted therefor.

baz --> \"baz\"

baz \"bar\" --> \"baz \\\"bar\\\"\""
 (interactive "r*")
 (goto-char end)
 (prin1 (buffer-substring-no-properties start end) (current-buffer))
 (delete-region start end))


__
Andreas Roehler

Re: Unmentioned "stringify" aspect in docu buffer-substring-no-properties

[David Kastrup]

Andreas Roehler <andreas.roehler@online.de> writes:

> Richard Stallman schrieb:
>> Would people please check those files for accuracy one more time?
>> They are the files listed in FOR-RELEASE with just one name.
>
>> text.texi
> IMO:
> Unmentioned "stringify" aspect in
> `buffer-substring-no-properties'; also concerns
> `buffer-substring'
>
> AFAIU there are two different meanings of string, which
> are mixed up in naming and function of
>
> `buffer-substring-no-properties':
>
> 1) it takes a portion of the buffer, but not necessary
>  of a type `string', so `substring' might mislead
>  here (nonetheless, would not ask for changing this
>  name for compatiblity reasons)

Uh what?  Of course the type is `string'.

> 2) it stringifies these portion, changes the type of it

It does nothing of the sort.

> ;;; check the following examples in a buffer starting
>   with it, in order to have the Start-End-Entries
>   set as given
>
> (defun foo ()
> " "
> (interactive "*")
> )
>
> (buffer-substring-no-properties 34 37)"e \""

There is no "stringification" done by buffer-substring-no-properties.
The Lisp reader prints the result of the evaluation in string syntax,
that is all.

> It happened to be a discussion in de.comp.editoren,
> concerning a stringify function
>
> The (still disputed) result exploits just the
> mentioned quality.

It doesn't.

> (defun region2string (start end)
> "Make a string from the chars of a region.
> Doublequotes inside will be quoted therefor.
>
> baz --> \"baz\"
>
> baz \"bar\" --> \"baz \\\"bar\\\"\""
> (interactive "r*")
> (goto-char end)
> (prin1 (buffer-substring-no-properties start end) (current-buffer))
> (delete-region start end))

The string quotes get added by prin1, not by
buffer-substring-no-properties.  You should really try reading up some
basics in the Emacs Lisp tutorial.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Unmentioned "stringify" aspect in docu buffer-substring-no-properties

[Andreas Roehler]

David Kastrup schrieb:
> Andreas Roehler <andreas.roehler@online.de> writes:
>
>   
>> Richard Stallman schrieb:
>>     
>>> Would people please check those files for accuracy one more time?
>>> They are the files listed in FOR-RELEASE with just one name.
>>>       
>>> text.texi
>>>       
>> IMO:
>> Unmentioned "stringify" aspect in
>> `buffer-substring-no-properties'; also concerns
>> `buffer-substring'
>>
>> AFAIU there are two different meanings of string, which
>> are mixed up in naming and function of
>>
>> `buffer-substring-no-properties':
>>
>> 1) it takes a portion of the buffer, but not necessary
>>  of a type `string', so `substring' might mislead
>>  here (nonetheless, would not ask for changing this
>>  name for compatiblity reasons)
>>     
>
> Uh what?  Of course the type is `string'.
>
>   
>> 2) it stringifies these portion, changes the type of it
>>     
>
> It does nothing of the sort.
>
>   
>> ;;; check the following examples in a buffer starting
>>   with it, in order to have the Start-End-Entries
>>   set as given
>>
>> (defun foo ()
>> " "
>> (interactive "*")
>> )
>>
>> (buffer-substring-no-properties 34 37)"e \""
>>     
>
> There is no "stringification" done by buffer-substring-no-properties.
> The Lisp reader prints the result of the evaluation in string syntax,
> that is all.
>
>   
>> It happened to be a discussion in de.comp.editoren,
>> concerning a stringify function
>>
>> The (still disputed) result exploits just the
>> mentioned quality.
>>     
>
> It doesn't.
>
>   
>> (defun region2string (start end)
>> "Make a string from the chars of a region.
>> Doublequotes inside will be quoted therefor.
>>
>> baz --> \"baz\"
>>
>> baz \"bar\" --> \"baz \\\"bar\\\"\""
>> (interactive "r*")
>> (goto-char end)
>> (prin1 (buffer-substring-no-properties start end) (current-buffer))
>> (delete-region start end))
>>     
>
> The string quotes get added by prin1, not by
> buffer-substring-no-properties.  You should really try reading up some
> basics in the Emacs Lisp tutorial.
>
>   
Please look at the example given above

(setq baz (buffer-substring-no-properties 34 37))

baz"e \""

there was no prin1 between, AFAIS.

The behavior of prin1 BTW was not the item.

Re: Unmentioned "stringify" aspect in docu buffer-substring-no-properties

[David Kastrup]

Andreas Roehler <andreas.roehler@easy-emacs.de> writes:

[...]

> The behavior of prin1 BTW was not the item.

You mailed this to me in private already, and I answered it in private
already.  There is no point in posting it to the list again (or
alternatively, to have posted it to me privately before): you are just
wasting people's resources by addressing independent channels with the
same material.

So please at least use the Cc function for addressing multiple
recipients so that the answers also reach all channels.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Unmentioned "stringify" aspect in docu buffer-substring-no-properties

[Miles Bader]

Andreas Roehler <andreas.roehler@easy-emacs.de> writes:
> (setq baz (buffer-substring-no-properties 34 37))
>
> baz"e \""
>
> there was no prin1 between, AFAIS.
>
> The behavior of prin1 BTW was not the item.

prin1 (or some internal equivalent) is what's used to insert the result
of evaluating the form (in the *scratch* buffer or in the minibuffer
when using M-x eval-expression).

Try explicitly using prin1 yourself, e.g.:

   (prin1 (buffer-substring-no-properties 34 37))
   "e \"""e \""

prin1 returns its argument, which is then printed by the interaction
loop, so you get two things printed in *scratch*.  Note that they are
the same, as the explicit and implicit calls to prin1 performed the same
ascii-encoding of the value.

-Miles

-- 
[|nurgle|]  ddt- demonic? so quake will have an evil kinda setting? one that
            will  make every christian in the world foamm at the mouth?
[iddt]      nurg, that's the goal

Re: Unmentioned "stringify" aspect in docu buffer-substring-no-properties

[Andreas Roehler]

>> text.texi
> IMO:
> Unmentioned "stringify" aspect in
> `buffer-substring-no-properties'; also concerns
> `buffer-substring'

As explanation of `buffer-substring' stipulates

"This function returns a string" I want to relativate
my remarks. Seems the mistake is my own so far.

Meanwhile I discovered that evaluation of the given
example to `buffer-substring' produces a different
result as shown in the manual.

Will post this with an other subject line.

__
Andreas Roehler