Re: How to circumvent warning in batch mode

[Decebal]

On Oct 9, 3:43 pm, Kevin Rodgers <kevin.d.rodg...@gmail.com> wrote:
> > The input file is quite big and I get:
> >     File input is large (31MB), really open? (y or n)
> > Is there a way to circumvent this?
>
> let-bind large-file-warning-threshold to nil around the call to find-file.

I allready use:
    (switch-to-buffer (find-file-noselect input-file t t))

> > Is there a way to do this more efficient? This script needs about 20
> > seconds. When doing it with a Perl script, it takes about 6 seconds.
>
> 1. Put the code in a file (FILE.el) and byte-compile it.  Then instead of
>     --eval 'CODE' on the command line, use --load FILE.elc

It is part of a script. So I think the compilation would be faster as
a load from disc. Also: how can I give parameters to an .elc
 file?

> 2. It looks like you are doing a lot of unnecessary string allocation with
>     concat and substring:
>
>     For every character after the first character in the match, you double the
>     length of the replacement string until it is at least as long as the 
> length
>     of the match string, then you only use the number of characters that were 
> in
>     the match string anyway.  Change the loop to:
>
>      (while (re-search-forward "^ +" nil t)
>        (setq match-length (- (point) (match-beginning 0)))
>        (if (> match-length 1)
>           (replace-match (make-string match-length ?@))
>         (replace-match "@")))

Will not work in my case. In the example the replace string is only a
character long, but it could also be for example '1234567890'.


>     That could be improved further by caching each replacement string of 
> length
>     > 1, so it is only allocated once... But now, I can see that my version
>     using make-string does the same amount of string allocation as yours using
>     substring, and that your use of concat is infrequent (only needed when the
>     match string jumps to a larger length than has been seen so far).  So 
> caching
>     the replacement string (in an array, indexed by its length) is the way to 
> go.

Making the replacement string longer takes only about a second. The
real work is in the replace-match. Only the coders of Emacs can change
that.


> > Instead of the '@' or chr$(64) I would like to use a nbsp or chr
> > $(160). But then the script needs almost 3 minutes. Also every space
> > is replaced by two characters chr$(194) + chr$(160).
> > What is going wrong here?
>
> In UTF-8, NBSP is 2 bytes: decimal 194 160 aka hex 00C2 00A0.

That explains the two characters, but why does it akes so long?

Because I now use
    (switch-to-buffer (find-file-noselect input-file t t))
I do not have this problem anymore.