string-to-char

string-to-char

[martin rudalics]

 From the Elisp manual on `string-to-char':

      This function may be eliminated in the future if it does not seem
      useful enough to retain.

Given that some 60 files of current Emacs use `string-to-char' these
lines appear incongruous and should be eliminated.

Re: string-to-char

[Juanma Barranquero]

On 11/27/06, martin rudalics <rudalics@gmx.at> wrote:

> Given that some 60 files of current Emacs use `string-to-char'

And some of those uses are quite weird, BTW:

 - In erc/erc.el:
    (separator (make-string erc-fill-column (string-to-char "=")))
    (make-string (length x) (string-to-char "b"))

 - In progmodes/fortran.el:
    (or (equal char (string-to-char " "))

Aren't these redundant? (I don't think the unibyte/multibyte issue is
relevant in any of them...)

                    /L/e/k/t/u

Re: string-to-char

[Nick Roberts]

 > And some of those uses are quite weird, BTW:
 > 
 >  - In erc/erc.el:
 >     (separator (make-string erc-fill-column (string-to-char "=")))
 >     (make-string (length x) (string-to-char "b"))
 > 
 >  - In progmodes/fortran.el:
 >     (or (equal char (string-to-char " "))
 > 
 > Aren't these redundant? (I don't think the unibyte/multibyte issue is
 > relevant in any of them...)

Very probably.  The problem with changing them and the large numbers of files
to which you are applying trivial fixes is that the code being pretested is no
longer that in the repository.  I think it's best to follow the adage: "If it
ain't broke then don't fix it.".  At least, until After The Release (TM).


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: string-to-char

[Juanma Barranquero]

On 11/27/06, Nick Roberts <nickrob@snap.net.nz> wrote:

> Very probably.  The problem with changing them and the large numbers of files
> to which you are applying trivial fixes is that the code being pretested is no
> longer that in the repository.

Well, yeah, except that: 1) the changes I've done are really trivial
(you're right on that account) and it would be very surprising if they
broke something (and I'm assuming you're referring to the \s changes,
as the other are mostly doc fixes), and 2) the 22.0.91 pretest has not
been announced, AFAIK. At least, I'm in the pretester's list and
didn't receive any announce (I received one in the devel list). So I
don't think it's being tested, more or less than the CVS HEAD usually
is. I would not be doing changes if there were a public pretest.

                    /L/e/k/t/u

Re: string-to-char

[Nick Roberts]

 >                              ... and 2) the 22.0.91 pretest has not
 > been announced, AFAIK. At least, I'm in the pretester's list and
 > didn't receive any announce (I received one in the devel list). So I
 > don't think it's being tested, more or less than the CVS HEAD usually
 > is. I would not be doing changes if there were a public pretest.

We're either in pretest or we're not.  It's been reported on LWN, reports
are coming in... so it seems pretty public.  Having a limbo state of quasi
pretest seems a bit meaningless to me.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: string-to-char

[Richard Stallman]

I announced the pretest to the list of pretesters
but you are not on that list.  If you were on the list before,
you were removed, probably because of not responding when I asked you
if you wanted to remain on the list.

Re: string-to-char

[Juanma Barranquero]

On 11/29/06, Richard Stallman <rms@gnu.org> wrote:

> I announced the pretest to the list of pretesters
> but you are not on that list.  If you were on the list before,
> you were removed, probably because of not responding when I asked you
> if you wanted to remain on the list.

My sent-email folder on Gmail contains the attached e-mail. (You
wrote, I think, to lektu@terra.es, which is redirected to Gmail, so I
received it and answered it from my Gmail account).

                    /L/e/k/t/u


> X-Gmail-Received: 754ac04ec11b8e70f7732b69cd7f7236544771b2
> Received: by 10.82.136.11 with HTTP; Sun, 29 Oct 2006 10:49:32 -0800 (PST)
> Message-ID:
> <f7ccd24b0610291049o78903f71mff6468463193cd45@mail.gmail.com>
> Date: Sun, 29 Oct 2006 19:49:32 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> To: rms@gnu.org
> Subject: Re: Emacs pretesting (Juanma Barranquero <lektu@terra.es>)
> In-Reply-To: <E1GeFhO-0007zP-JS@fencepost.gnu.org>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8; format=flowed
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> References: <E1GeFhO-0007zP-JS@fencepost.gnu.org>
> Delivered-To: lekktu@gmail.com
>
> On 10/29/06, Richard Stallman <rms@gnu.org> wrote:
> > If you are still interested in being on the Emacs pretest list,
> > would you please tell me?
>
> Yes, but please use the current e-mail: lekktu@gmail.com.
>
> --
>                     /L/e/k/t/u

Re: string-to-char

[Richard Stallman]

Perhaps the change in email address caused my script to think there
was no reply from you.  I put you back in the list.

Re: string-to-char

[Richard Stallman]

    And some of those uses are quite weird, BTW:

     - In erc/erc.el:
	(separator (make-string erc-fill-column (string-to-char "=")))
	(make-string (length x) (string-to-char "b"))

     - In progmodes/fortran.el:
	(or (equal char (string-to-char " "))

    Aren't these redundant? (I don't think the unibyte/multibyte issue is
    relevant in any of them...)

Please feel free to simplify them.

Re: string-to-char

[Glenn Morris]

"Juanma Barranquero" wrote:

> - In progmodes/fortran.el:
>    (or (equal char (string-to-char " "))

I'll get rid of that one, which as you say is unnecessary.

Re: string-to-char

[Stefan Monnier]

>      This function may be eliminated in the future if it does not seem
>      useful enough to retain.

> Given that some 60 files of current Emacs use `string-to-char' these
> lines appear incongruous and should be eliminated.

I think (aref STR 0) is just as good.  And as someone else mentioned,
string-to-char is surprisingly often used in odd cases where the whole thing
could be completely removed.


        Stefan