Why do I need to eval this?

Why do I need to eval this?

[Arnaldo Mandel]

Here is a short utility command that is useful to those writing
Portuguese on US keyboards:

(defun crases (daqui)
  "Offers all grave-accented chars to be corrected to the corresponding tilda.
Argument DAQUI starts search from point."
  (interactive "P")
  (let ((start (if daqui (point) (point-min))))
    (save-excursion
      (query-replace-regexp-eval "[àòÀÒ]" 
                                 '(cdr (assoc (match-string-no-properties 0)
                                              '(("à" . "ã") ("ò" . "õ")
                                                ("À" . "Ã") ("Ò" . "Õ"))))
                                 nil start (point-max)))))

If I either byte-compile it or load it uncompiled from a file, it
doesn't work: it finds the characters that have to be replaced,
but replaces with nil.  On the other hand, if I eval this expression
(C-x C-e), it works perfectly.  The behavior is the same in emacs 21
and 22.

Any idea on what is going on?

am

-- 
Arnaldo Mandel                        
am@ime.usp.br

Re: Why do I need to eval this?

[Reiner Steib]

On Mon, Jan 15 2007, Arnaldo Mandel wrote:

> Here is a short utility command that is useful to those writing
> Portuguese on US keyboards:

What's wrong with `M-x set-input-method RET portuguese-prefix RET'? 

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Why do I need to eval this?

[HS]

Interessante a sua idéia, mas acho que não consegui fazer funcionar.
Agora me diz se você sabe fazer isto:
Eu queria que todas palavras terminando em `ao` fossem substituidas por
`ão` assim eu poderia escrever chao, nao, coracao e elas seriam
arrumadas na hora.
Normalmente eu resolvo isto com as abbrevs, mas neste caso é uma
regex, então nao sei.
Você tem alguma idéia ?
Sds
Hugo


Arnaldo Mandel escreveu:

> Here is a short utility command that is useful to those writing
> Portuguese on US keyboards:
>
> (defun crases (daqui)
>   "Offers all grave-accented chars to be corrected to the corresponding tilda.
> Argument DAQUI starts search from point."
>   (interactive "P")
>   (let ((start (if daqui (point) (point-min))))
>     (save-excursion
>       (query-replace-regexp-eval "[àòÀÒ]"
>                                  '(cdr (assoc (match-string-no-properties 0)
>                                               '(("à" . "ã") ("ò" . "õ")
>                                                 ("À" . "Ã") ("Ò" . "Õ"))))
>                                  nil start (point-max)))))
>
> If I either byte-compile it or load it uncompiled from a file, it
> doesn't work: it finds the characters that have to be replaced,
> but replaces with nil.  On the other hand, if I eval this expression
> (C-x C-e), it works perfectly.  The behavior is the same in emacs 21
> and 22.
>
> Any idea on what is going on?
>
> am
> 
> -- 
> Arnaldo Mandel                        
> am@ime.usp.br

Re: Why do I need to eval this?

[Arnaldo Mandel]

Reiner Steib wrote (on Jan 15, 2007):
 > On Mon, Jan 15 2007, Arnaldo Mandel wrote:
 > 
 > > Here is a short utility command that is useful to those writing
 > > Portuguese on US keyboards:
 > 
 > What's wrong with `M-x set-input-method RET portuguese-prefix RET'? 

Unrelated; I am already using an adequate input-method.

US keyboards have ` and ~ on the same key, ~ is shifted `.  The key is 
in the NW corner, just below ESC.  In order to get, say ã (a tilda),
the input method I use requires one to key first a tilda, then a.

It often happens that fingers stumble, and instead of Shift-`, just a
` is keyed, so, instead of ã (a tilda) one gets à (a grave).  This
occurs quite frequently.

That little function helps correcting these errors afterwards, on
a single swipe over the buffer, so that even when one notices that the
error occurred, one does not need to break the typing to correct it. 

So, that gives the rationale for designing the function.  However,
even if there was no reason at all for it, the puzzle remains:

    when evaluated in a given session, it performs according to
    specification; when loaded, whether byte-compiled or not, it
    doesn't.

am

-- 
Arnaldo Mandel                        
am@ime.usp.br

Re: Why do I need to eval this?

[B. T. Raven]

"Arnaldo Mandel" <am@ime.usp.br> wrote in message
news:mailman.3142.1168948826.2155.help-gnu-emacs@gnu.org...
> Reiner Steib wrote (on Jan 15, 2007):
>  > On Mon, Jan 15 2007, Arnaldo Mandel wrote:
>  >
>  > > Here is a short utility command that is useful to those writing
>  > > Portuguese on US keyboards:
>  >
>  > What's wrong with `M-x set-input-method RET portuguese-prefix RET'?
>
> Unrelated; I am already using an adequate input-method.
>
> US keyboards have ` and ~ on the same key, ~ is shifted `.  The key is
> in the NW corner, just below ESC.  In order to get, say ã (a tilda),
> the input method I use requires one to key first a tilda, then a.
>
> It often happens that fingers stumble, and instead of Shift-`, just a
> ` is keyed, so, instead of ã (a tilda) one gets à (a grave).  This
> occurs quite frequently.
>
> That little function helps correcting these errors afterwards, on
> a single swipe over the buffer, so that even when one notices that the
> error occurred, one does not need to break the typing to correct it.
>
> So, that gives the rationale for designing the function.  However,
> even if there was no reason at all for it, the puzzle remains:
>
>     when evaluated in a given session, it performs according to
>     specification; when loaded, whether byte-compiled or not, it
>     doesn't.
>
> am

I think is has to be a coding system problem. I copy pasted your lisp code
into a buffer and then saved the buffer with an .el extension. After M-x
load-file and M-x crases it worked for changing all the grave accents to
tildes in the lisp source. I would recommend that you change your default
encoding to utf-8.

Ed.

Re: Why do I need to eval this?

[Arnaldo Mandel]

B. T. Raven wrote (on Jan 17, 2007):
 > 
 > I think is has to be a coding system problem. 

I cannot understand how that would come to be.  Can you (or somebody
else) give me a hint of why it goes wrong?

 >                                               I copy pasted your lisp code
 > into a buffer and then saved the buffer with an .el extension. After M-x
 > load-file and M-x crases it worked for changing all the grave accents to
 > tildes in the lisp source. I would recommend that you change your default
 > encoding to utf-8.

I have always uses emacs --unibyte, and everything here is iso8859-1
encoded.  I suppose it would be a real PITA moving to utf-8.

Anyway, I solved my problem reimplementing the function in a less
elegant way (used substring searches instead of the assoc list).  So,
what remains is just to get a real understanding of what went wrong.
I do not like to see (apparent) bugs going away by simple finesse, I
want to be able to really avoid them.

am

-- 
Arnaldo Mandel                        
am@ime.usp.br

Re: Why do I need to eval this?

[B. T. Raven]

"Arnaldo Mandel" <am@ime.usp.br> wrote in message
news:mailman.3308.1169210776.2155.help-gnu-emacs@gnu.org...
> B. T. Raven wrote (on Jan 17, 2007):
>  >
>  > I think is has to be a coding system problem.
>
> I cannot understand how that would come to be.  Can you (or somebody
> else) give me a hint of why it goes wrong?
>
>  >                                               I copy pasted your lisp
code
>  > into a buffer and then saved the buffer with an .el extension. After
M-x
>  > load-file and M-x crases it worked for changing all the grave accents
to
>  > tildes in the lisp source. I would recommend that you change your
default
>  > encoding to utf-8.
>
> I have always uses emacs --unibyte, and everything here is iso8859-1
> encoded.  I suppose it would be a real PITA moving to utf-8.

It is a PITA but that seems to be the way the world is going.

>
> Anyway, I solved my problem reimplementing the function in a less
> elegant way (used substring searches instead of the assoc list).  So,
> what remains is just to get a real understanding of what went wrong.
> I do not like to see (apparent) bugs going away by simple finesse, I
> want to be able to really avoid them.
>

It seems that your function "can't" be wrong if you're using unibyte but,
just out of curiosity, check the representation of all the glyphs in
question in both your lisp source and the target file using something like
C-x =, just to be sure.

> am
>
> --
> Arnaldo Mandel
> am@ime.usp.br
>
>