ediff and coding systems

ediff and coding systems

[Dan Nicolaescu]

lisp/term/mac-win.el from CVS trunk uses:  -*-coding: iso-2022-7bit;-*-
and the same file on the emacs-unicode-2 uses: -*-coding: utf-8 

When doing M-x ediff for the above 2 files a *Warning* buffer pops up
for each hunk:

These default coding systems were tried to encode text
in the buffer ` *ediff-tmp*':
  iso-latin-1
However, each of them encountered characters it couldn't encode:
  iso-latin-1 cannot encode these: ? ? ? ? ? ? ? ? ? ? ...

Click on a character (or switch to this window by `C-x o'
and select the characters by RET) to jump to the place it appears,
where `C-u C-x =' will give information about it.

Select one of the safe coding systems listed below,
or cancel the writing with C-g and edit the buffer
   to remove or modify the problematic characters,
or specify any other coding system (and risk losing
   the problematic characters).

  utf-8 utf-16 utf-16 utf-16 utf-16be utf-16le iso-2022-7bit

with the question "Select coding system (default mule-utf-8):"

Would it be possible for ediff to avoid this?

Re: ediff and coding systems

[Eli Zaretskii]

Michael, could you please look into the following report?  TIA

> From: Dan Nicolaescu <dann@ics.uci.edu>
> Date: Sat, 20 Oct 2007 08:21:10 -0700
> 
> 
> lisp/term/mac-win.el from CVS trunk uses:  -*-coding: iso-2022-7bit;-*-
> and the same file on the emacs-unicode-2 uses: -*-coding: utf-8 
> 
> When doing M-x ediff for the above 2 files a *Warning* buffer pops up
> for each hunk:
> 
> These default coding systems were tried to encode text
> in the buffer ` *ediff-tmp*':
>   iso-latin-1
> However, each of them encountered characters it couldn't encode:
>   iso-latin-1 cannot encode these: ? ? ? ? ? ? ? ? ? ? ...
> 
> Click on a character (or switch to this window by `C-x o'
> and select the characters by RET) to jump to the place it appears,
> where `C-u C-x =' will give information about it.
> 
> Select one of the safe coding systems listed below,
> or cancel the writing with C-g and edit the buffer
>    to remove or modify the problematic characters,
> or specify any other coding system (and risk losing
>    the problematic characters).
> 
>   utf-8 utf-16 utf-16 utf-16 utf-16be utf-16le iso-2022-7bit
> 
> with the question "Select coding system (default mule-utf-8):"
> 
> Would it be possible for ediff to avoid this?
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
> 

Re: ediff and coding systems

[Stefan Monnier]

> When doing M-x ediff for the above 2 files a *Warning* buffer pops up
> for each hunk:

Can you try it with ediff-buffers?  That should work (because ediff can
always save those buffers using emacs-mule coding system so both files will
have the same coding system, which is a necessary prerequisite to be able
to get meaningful diffs).


        Stefan

Re: ediff and coding systems

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > > When doing M-x ediff for the above 2 files a *Warning* buffer pops up
  > > for each hunk:
  > 
  > Can you try it with ediff-buffers?  That should work (because ediff can
  > always save those buffers using emacs-mule coding system so both files will
  > have the same coding system, which is a necessary prerequisite to be able
  > to get meaningful diffs).

Makes no difference. 

I have LANG set to C. If I set it to en_US.UTF-8 everything works fine...

Re: ediff and coding systems

[Michael Kifer]

I cannot reproduce this. I need a simple testcase.
I took lisp/term/mac-win.el and created two copies. One with iso-2022-7bit
and the other with utf-8. But ediffing them did not bring any warnings.

> Michael, could you please look into the following report?  TIA
> 
> > From: Dan Nicolaescu <dann@ics.uci.edu>
> > Date: Sat, 20 Oct 2007 08:21:10 -0700
> > 
> > 
> > lisp/term/mac-win.el from CVS trunk uses:  -*-coding: iso-2022-7bit;-*-
> > and the same file on the emacs-unicode-2 uses: -*-coding: utf-8 
> > 
> > When doing M-x ediff for the above 2 files a *Warning* buffer pops up
> > for each hunk:
> > 
> > These default coding systems were tried to encode text
> > in the buffer ` *ediff-tmp*':
> >   iso-latin-1
> > However, each of them encountered characters it couldn't encode:
> >   iso-latin-1 cannot encode these: ? ? ? ? ? ? ? ? ? ? ...
> > 
> > Click on a character (or switch to this window by `C-x o'
> > and select the characters by RET) to jump to the place it appears,
> > where `C-u C-x =' will give information about it.
> > 
> > Select one of the safe coding systems listed below,
> > or cancel the writing with C-g and edit the buffer
> >    to remove or modify the problematic characters,
> > or specify any other coding system (and risk losing
> >    the problematic characters).
> > 
> >   utf-8 utf-16 utf-16 utf-16 utf-16be utf-16le iso-2022-7bit
> > 
> > with the question "Select coding system (default mule-utf-8):"
> > 
> > Would it be possible for ediff to avoid this?
> > 
> > 
> > _______________________________________________
> > Emacs-devel mailing list
> > Emacs-devel@gnu.org
> > http://lists.gnu.org/mailman/listinfo/emacs-devel
> > 
> 

Re: ediff and coding systems

[Dan Nicolaescu]

kifer@cs.sunysb.edu (Michael Kifer) writes:

  > I cannot reproduce this. I need a simple testcase.
  > I took lisp/term/mac-win.el and created two copies. One with iso-2022-7bit
  > and the other with utf-8. But ediffing them did not bring any warnings.

Please try 
env LANG=C emacs -q 
and then ediff the 2 files.


  > > Michael, could you please look into the following report?  TIA
  > > 
  > > > From: Dan Nicolaescu <dann@ics.uci.edu>
  > > > Date: Sat, 20 Oct 2007 08:21:10 -0700
  > > > 
  > > > 
  > > > lisp/term/mac-win.el from CVS trunk uses:  -*-coding: iso-2022-7bit;-*-
  > > > and the same file on the emacs-unicode-2 uses: -*-coding: utf-8 
  > > > 
  > > > When doing M-x ediff for the above 2 files a *Warning* buffer pops up
  > > > for each hunk:
  > > > 
  > > > These default coding systems were tried to encode text
  > > > in the buffer ` *ediff-tmp*':
  > > >   iso-latin-1
  > > > However, each of them encountered characters it couldn't encode:
  > > >   iso-latin-1 cannot encode these: ? ? ? ? ? ? ? ? ? ? ...
  > > > 
  > > > Click on a character (or switch to this window by `C-x o'
  > > > and select the characters by RET) to jump to the place it appears,
  > > > where `C-u C-x =' will give information about it.
  > > > 
  > > > Select one of the safe coding systems listed below,
  > > > or cancel the writing with C-g and edit the buffer
  > > >    to remove or modify the problematic characters,
  > > > or specify any other coding system (and risk losing
  > > >    the problematic characters).
  > > > 
  > > >   utf-8 utf-16 utf-16 utf-16 utf-16be utf-16le iso-2022-7bit
  > > > 
  > > > with the question "Select coding system (default mule-utf-8):"
  > > > 
  > > > Would it be possible for ediff to avoid this?
  > > > 
  > > > 
  > > > _______________________________________________
  > > > Emacs-devel mailing list
  > > > Emacs-devel@gnu.org
  > > > http://lists.gnu.org/mailman/listinfo/emacs-devel
  > > > 
  > > 

Re: ediff and coding systems

[Michael Kifer]

Same thing - no luck.

> kifer@cs.sunysb.edu (Michael Kifer) writes:
> 
>   > I cannot reproduce this. I need a simple testcase.
>   > I took lisp/term/mac-win.el and created two copies. One with iso-2022-7bit
>   > and the other with utf-8. But ediffing them did not bring any warnings.
> 
> Please try 
> env LANG=C emacs -q 
> and then ediff the 2 files.
> 
> 
>   > > Michael, could you please look into the following report?  TIA
>   > > 
>   > > > From: Dan Nicolaescu <dann@ics.uci.edu>
>   > > > Date: Sat, 20 Oct 2007 08:21:10 -0700
>   > > > 
>   > > > 
>   > > > lisp/term/mac-win.el from CVS trunk uses:  -*-coding: iso-2022-7bit;-*-
>   > > > and the same file on the emacs-unicode-2 uses: -*-coding: utf-8 
>   > > > 
>   > > > When doing M-x ediff for the above 2 files a *Warning* buffer pops up
>   > > > for each hunk:
>   > > > 
>   > > > These default coding systems were tried to encode text
>   > > > in the buffer ` *ediff-tmp*':
>   > > >   iso-latin-1
>   > > > However, each of them encountered characters it couldn't encode:
>   > > >   iso-latin-1 cannot encode these: ? ? ? ? ? ? ? ? ? ? ...
>   > > > 
>   > > > Click on a character (or switch to this window by `C-x o'
>   > > > and select the characters by RET) to jump to the place it appears,
>   > > > where `C-u C-x =' will give information about it.
>   > > > 
>   > > > Select one of the safe coding systems listed below,
>   > > > or cancel the writing with C-g and edit the buffer
>   > > >    to remove or modify the problematic characters,
>   > > > or specify any other coding system (and risk losing
>   > > >    the problematic characters).
>   > > > 
>   > > >   utf-8 utf-16 utf-16 utf-16 utf-16be utf-16le iso-2022-7bit
>   > > > 
>   > > > with the question "Select coding system (default mule-utf-8):"
>   > > > 
>   > > > Would it be possible for ediff to avoid this?
>   > > > 
>   > > > 
>   > > > _______________________________________________
>   > > > Emacs-devel mailing list
>   > > > Emacs-devel@gnu.org
>   > > > http://lists.gnu.org/mailman/listinfo/emacs-devel
>   > > > 
>   > > 
> 

Re: ediff and coding systems

[Dan Nicolaescu]

kifer@cs.sunysb.edu (Michael Kifer) writes:

  > Same thing - no luck.

What version of emacs are you using? 
With 22.1 it works fine for me, with CVS trunk it does not... 

  > > kifer@cs.sunysb.edu (Michael Kifer) writes:
  > > 
  > >   > I cannot reproduce this. I need a simple testcase.
  > >   > I took lisp/term/mac-win.el and created two copies. One with iso-2022-7bit
  > >   > and the other with utf-8. But ediffing them did not bring any warnings.
  > > 
  > > Please try 
  > > env LANG=C emacs -q 
  > > and then ediff the 2 files.
  > > 
  > > 
  > >   > > Michael, could you please look into the following report?  TIA
  > >   > > 
  > >   > > > From: Dan Nicolaescu <dann@ics.uci.edu>
  > >   > > > Date: Sat, 20 Oct 2007 08:21:10 -0700
  > >   > > > 
  > >   > > > 
  > >   > > > lisp/term/mac-win.el from CVS trunk uses:  -*-coding: iso-2022-7bit;-*-
  > >   > > > and the same file on the emacs-unicode-2 uses: -*-coding: utf-8 
  > >   > > > 
  > >   > > > When doing M-x ediff for the above 2 files a *Warning* buffer pops up
  > >   > > > for each hunk:
  > >   > > > 
  > >   > > > These default coding systems were tried to encode text
  > >   > > > in the buffer ` *ediff-tmp*':
  > >   > > >   iso-latin-1
  > >   > > > However, each of them encountered characters it couldn't encode:
  > >   > > >   iso-latin-1 cannot encode these: ? ? ? ? ? ? ? ? ? ? ...
  > >   > > > 
  > >   > > > Click on a character (or switch to this window by `C-x o'
  > >   > > > and select the characters by RET) to jump to the place it appears,
  > >   > > > where `C-u C-x =' will give information about it.
  > >   > > > 
  > >   > > > Select one of the safe coding systems listed below,
  > >   > > > or cancel the writing with C-g and edit the buffer
  > >   > > >    to remove or modify the problematic characters,
  > >   > > > or specify any other coding system (and risk losing
  > >   > > >    the problematic characters).
  > >   > > > 
  > >   > > >   utf-8 utf-16 utf-16 utf-16 utf-16be utf-16le iso-2022-7bit
  > >   > > > 
  > >   > > > with the question "Select coding system (default mule-utf-8):"
  > >   > > > 
  > >   > > > Would it be possible for ediff to avoid this?
  > >   > > > 
  > >   > > > 
  > >   > > > _______________________________________________
  > >   > > > Emacs-devel mailing list
  > >   > > > Emacs-devel@gnu.org
  > >   > > > http://lists.gnu.org/mailman/listinfo/emacs-devel
  > >   > > > 
  > >   > > 
  > > 

Re: ediff and coding systems

[Michael Kifer]

I am using 23.0.50 - the current CVS version.


> kifer@cs.sunysb.edu (Michael Kifer) writes:
> 
>   > Same thing - no luck.
> 
> What version of emacs are you using? 
> With 22.1 it works fine for me, with CVS trunk it does not... 
> 
>   > > kifer@cs.sunysb.edu (Michael Kifer) writes:
>   > > 
>   > >   > I cannot reproduce this. I need a simple testcase.
>   > >   > I took lisp/term/mac-win.el and created two copies. One with iso-2022-7bit
>   > >   > and the other with utf-8. But ediffing them did not bring any warnings.
>   > > 
>   > > Please try 
>   > > env LANG=C emacs -q 
>   > > and then ediff the 2 files.
>   > > 
>   > > 
>   > >   > > Michael, could you please look into the following report?  TIA
>   > >   > > 
>   > >   > > > From: Dan Nicolaescu <dann@ics.uci.edu>
>   > >   > > > Date: Sat, 20 Oct 2007 08:21:10 -0700
>   > >   > > > 
>   > >   > > > 
>   > >   > > > lisp/term/mac-win.el from CVS trunk uses:  -*-coding: iso-2022-7bit;-*-
>   > >   > > > and the same file on the emacs-unicode-2 uses: -*-coding: utf-8 
>   > >   > > > 
>   > >   > > > When doing M-x ediff for the above 2 files a *Warning* buffer pops up
>   > >   > > > for each hunk:
>   > >   > > > 
>   > >   > > > These default coding systems were tried to encode text
>   > >   > > > in the buffer ` *ediff-tmp*':
>   > >   > > >   iso-latin-1
>   > >   > > > However, each of them encountered characters it couldn't encode:
>   > >   > > >   iso-latin-1 cannot encode these: ? ? ? ? ? ? ? ? ? ? ...
>   > >   > > > 
>   > >   > > > Click on a character (or switch to this window by `C-x o'
>   > >   > > > and select the characters by RET) to jump to the place it appears,
>   > >   > > > where `C-u C-x =' will give information about it.
>   > >   > > > 
>   > >   > > > Select one of the safe coding systems listed below,
>   > >   > > > or cancel the writing with C-g and edit the buffer
>   > >   > > >    to remove or modify the problematic characters,
>   > >   > > > or specify any other coding system (and risk losing
>   > >   > > >    the problematic characters).
>   > >   > > > 
>   > >   > > >   utf-8 utf-16 utf-16 utf-16 utf-16be utf-16le iso-2022-7bit
>   > >   > > > 
>   > >   > > > with the question "Select coding system (default mule-utf-8):"
>   > >   > > > 
>   > >   > > > Would it be possible for ediff to avoid this?
>   > >   > > > 
>   > >   > > > 
>   > >   > > > _______________________________________________
>   > >   > > > Emacs-devel mailing list
>   > >   > > > Emacs-devel@gnu.org
>   > >   > > > http://lists.gnu.org/mailman/listinfo/emacs-devel
>   > >   > > > 
>   > >   > > 
>   > > 
> 

Re: ediff and coding systems

[Dan Nicolaescu]

kifer@cs.sunysb.edu (Michael Kifer) writes:

  > I am using 23.0.50 - the current CVS version.

I can reproduce it with a version checked out this morning from CVS
trunk and one that is about 1 week old, I don't have anything older
than that. 

Is your version up to date?

Can anybody else reproduce it? I don't know much about coding systems,
so unfortunately I can't really debug this myself.

  > 
  > > kifer@cs.sunysb.edu (Michael Kifer) writes:
  > > 
  > >   > Same thing - no luck.
  > > 
  > > What version of emacs are you using? 
  > > With 22.1 it works fine for me, with CVS trunk it does not... 
  > > 
  > >   > > kifer@cs.sunysb.edu (Michael Kifer) writes:
  > >   > > 
  > >   > >   > I cannot reproduce this. I need a simple testcase.
  > >   > >   > I took lisp/term/mac-win.el and created two copies. One with iso-2022-7bit
  > >   > >   > and the other with utf-8. But ediffing them did not bring any warnings.
  > >   > > 
  > >   > > Please try 
  > >   > > env LANG=C emacs -q 
  > >   > > and then ediff the 2 files.
  > >   > > 
  > >   > > 
  > >   > >   > > Michael, could you please look into the following report?  TIA
  > >   > >   > > 
  > >   > >   > > > From: Dan Nicolaescu <dann@ics.uci.edu>
  > >   > >   > > > Date: Sat, 20 Oct 2007 08:21:10 -0700
  > >   > >   > > > 
  > >   > >   > > > 
  > >   > >   > > > lisp/term/mac-win.el from CVS trunk uses:  -*-coding: iso-2022-7bit;-*-
  > >   > >   > > > and the same file on the emacs-unicode-2 uses: -*-coding: utf-8 
  > >   > >   > > > 
  > >   > >   > > > When doing M-x ediff for the above 2 files a *Warning* buffer pops up
  > >   > >   > > > for each hunk:
  > >   > >   > > > 
  > >   > >   > > > These default coding systems were tried to encode text
  > >   > >   > > > in the buffer ` *ediff-tmp*':
  > >   > >   > > >   iso-latin-1
  > >   > >   > > > However, each of them encountered characters it couldn't encode:
  > >   > >   > > >   iso-latin-1 cannot encode these: ? ? ? ? ? ? ? ? ? ? ...
  > >   > >   > > > 
  > >   > >   > > > Click on a character (or switch to this window by `C-x o'
  > >   > >   > > > and select the characters by RET) to jump to the place it appears,
  > >   > >   > > > where `C-u C-x =' will give information about it.
  > >   > >   > > > 
  > >   > >   > > > Select one of the safe coding systems listed below,
  > >   > >   > > > or cancel the writing with C-g and edit the buffer
  > >   > >   > > >    to remove or modify the problematic characters,
  > >   > >   > > > or specify any other coding system (and risk losing
  > >   > >   > > >    the problematic characters).
  > >   > >   > > > 
  > >   > >   > > >   utf-8 utf-16 utf-16 utf-16 utf-16be utf-16le iso-2022-7bit
  > >   > >   > > > 
  > >   > >   > > > with the question "Select coding system (default mule-utf-8):"
  > >   > >   > > > 
  > >   > >   > > > Would it be possible for ediff to avoid this?
  > >   > >   > > > 
  > >   > >   > > > 
  > >   > >   > > > _______________________________________________
  > >   > >   > > > Emacs-devel mailing list
  > >   > >   > > > Emacs-devel@gnu.org
  > >   > >   > > > http://lists.gnu.org/mailman/listinfo/emacs-devel
  > >   > >   > > > 
  > >   > >   > > 
  > >   > > 
  > > 

Re: ediff and coding systems

[Leo]

On 2007-10-21 20:22 +0100, Dan Nicolaescu wrote:
> kifer@cs.sunysb.edu (Michael Kifer) writes:
>
>   > I am using 23.0.50 - the current CVS version.
>
> I can reproduce it with a version checked out this morning from CVS
> trunk and one that is about 1 week old, I don't have anything older
> than that. 
>
> Is your version up to date?
>
> Can anybody else reproduce it? I don't know much about coding systems,
> so unfortunately I can't really debug this myself.

I seemed to see a similar bug in the past.

http://news.gmane.org/group/gmane.emacs.pretest.bugs/thread=15737

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

       Use the most powerful email client -- http://gnus.org/

Re: ediff and coding systems

[Michael Kifer]

> kifer@cs.sunysb.edu (Michael Kifer) writes:
> 
>   > I am using 23.0.50 - the current CVS version.
> 
> I can reproduce it with a version checked out this morning from CVS
> trunk and one that is about 1 week old, I don't have anything older
> than that. 
> 
> Is your version up to date?

Yes - just updated it this morning.

> Can anybody else reproduce it? I don't know much about coding systems,
> so unfortunately I can't really debug this myself.
> 
>   > 
>   > > kifer@cs.sunysb.edu (Michael Kifer) writes:
>   > > 
>   > >   > Same thing - no luck.
>   > > 
>   > > What version of emacs are you using? 
>   > > With 22.1 it works fine for me, with CVS trunk it does not... 
>   > > 
>   > >   > > kifer@cs.sunysb.edu (Michael Kifer) writes:
>   > >   > > 
>   > >   > >   > I cannot reproduce this. I need a simple testcase.
>   > >   > >   > I took lisp/term/mac-win.el and created two copies. One with iso-2022-7bit
>   > >   > >   > and the other with utf-8. But ediffing them did not bring any warnings.
>   > >   > > 
>   > >   > > Please try 
>   > >   > > env LANG=C emacs -q 
>   > >   > > and then ediff the 2 files.
>   > >   > > 
>   > >   > > 
>   > >   > >   > > Michael, could you please look into the following report?  TIA
>   > >   > >   > > 
>   > >   > >   > > > From: Dan Nicolaescu <dann@ics.uci.edu>
>   > >   > >   > > > Date: Sat, 20 Oct 2007 08:21:10 -0700
>   > >   > >   > > > 
>   > >   > >   > > > 
>   > >   > >   > > > lisp/term/mac-win.el from CVS trunk uses:  -*-coding: iso-2022-7bit;-*-
>   > >   > >   > > > and the same file on the emacs-unicode-2 uses: -*-coding: utf-8 
>   > >   > >   > > > 
>   > >   > >   > > > When doing M-x ediff for the above 2 files a *Warning* buffer pops up
>   > >   > >   > > > for each hunk:
>   > >   > >   > > > 
>   > >   > >   > > > These default coding systems were tried to encode text
>   > >   > >   > > > in the buffer ` *ediff-tmp*':
>   > >   > >   > > >   iso-latin-1
>   > >   > >   > > > However, each of them encountered characters it couldn't encode:
>   > >   > >   > > >   iso-latin-1 cannot encode these: ? ? ? ? ? ? ? ? ? ? ...
>   > >   > >   > > > 
>   > >   > >   > > > Click on a character (or switch to this window by `C-x o'
>   > >   > >   > > > and select the characters by RET) to jump to the place it appears,
>   > >   > >   > > > where `C-u C-x =' will give information about it.
>   > >   > >   > > > 
>   > >   > >   > > > Select one of the safe coding systems listed below,
>   > >   > >   > > > or cancel the writing with C-g and edit the buffer
>   > >   > >   > > >    to remove or modify the problematic characters,
>   > >   > >   > > > or specify any other coding system (and risk losing
>   > >   > >   > > >    the problematic characters).
>   > >   > >   > > > 
>   > >   > >   > > >   utf-8 utf-16 utf-16 utf-16 utf-16be utf-16le iso-2022-7bit
>   > >   > >   > > > 
>   > >   > >   > > > with the question "Select coding system (default mule-utf-8):"
>   > >   > >   > > > 
>   > >   > >   > > > Would it be possible for ediff to avoid this?
>   > >   > >   > > > 
>   > >   > >   > > > 
>   > >   > >   > > > _______________________________________________
>   > >   > >   > > > Emacs-devel mailing list
>   > >   > >   > > > Emacs-devel@gnu.org
>   > >   > >   > > > http://lists.gnu.org/mailman/listinfo/emacs-devel
>   > >   > >   > > > 
>   > >   > >   > > 
>   > >   > > 
>   > > 
> 

Re: ediff and coding systems

[Dan Nicolaescu]

kifer@cs.sunysb.edu (Michael Kifer) writes:

  > > kifer@cs.sunysb.edu (Michael Kifer) writes:
  > > 
  > >   > I am using 23.0.50 - the current CVS version.
  > > 
  > > I can reproduce it with a version checked out this morning from CVS
  > > trunk and one that is about 1 week old, I don't have anything older
  > > than that. 
  > > 
  > > Is your version up to date?
  > 
  > Yes - just updated it this morning.

I don't have any other ideas of what to try...

Not related to this, but could you please look at these byte compile
warnings for viper-cmd.el?

In viper-next-line-carefully:
viper-cmd.el:2792:19:Warning: `next-line' used from Lisp code
That command is designed for interactive use only

In viper-next-line:
viper-cmd.el:3091:41:Warning: `next-line' used from Lisp code
That command is designed for interactive use only

In viper-previous-line:
viper-cmd.el:3134:41:Warning: `previous-line' used from Lisp code
That command is designed for interactive use only

Most similar warnings have been fixed in CVS, but for the above is not
obvious what to do.

In end of data:
viper-cmd.el:5099:1:Warning: the function `viper-heading-end' might
not be defined at runtime.

This one is strange


viper-cmd.el:5099:1:Warning: the following functions are not known to
be defined: quail-input-method, quail-start-translation,
    event-to-character,  character-to-event, viper-iconify, key-press-event-p, event-key,
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   These should be optimized out by the byte compiler.

Also viper-xemacs-p is about as long as (featurep 'emacs) and as
readable. Why not replace it?  Most similar macros have been replaced
in CVS.

Re: ediff and coding systems

[Kenichi Handa]

In article <200710211922.l9LJMQFX013338@oogie-boogie.ics.uci.edu>, Dan Nicolaescu <dann@ics.uci.edu> writes:

> Can anybody else reproduce it? I don't know much about coding systems,
> so unfortunately I can't really debug this myself.

I can reproduce it when I run Emacs with LANG=C, and try to
see the 5th (or 6th) different point where non-ASCII
charaters exist.  The calling sequence of read-coding-system
is this:

  read-coding-system("Select coding system (default mule-utf-8): " mule-utf-8)
  select-safe-coding-system-interactively(1 5557 (utf-8 ....))
  select-safe-coding-system(1 5557 nil nil "/tmp/fineDiffA155544eB")
  write-region(1 5557 "/tmp/fineDiffA155544eB" nil no-message)
  ediff-make-temp-file(#<buffer  *ediff-tmp*> "fineDiffA" "/tmp/fineDiffA155544eB")
  ediff-make-fine-diffs(5 noforce)
  ediff-install-fine-diff-if-necessary(5)
  ediff-next-difference(1)
  call-interactively(ediff-next-difference)

I don't know why ediff-make-temp-file is called, but perhaps
it should call write-region while binding
coding-system-for-write to `no-conversion' or `emacs-mule'.

---
Kenichi Handa
handa@m17n.org

Re: ediff and coding systems

[Michael Kifer]

> kifer@cs.sunysb.edu (Michael Kifer) writes:
> 
>   > > kifer@cs.sunysb.edu (Michael Kifer) writes:
>   > > 
>   > >   > I am using 23.0.50 - the current CVS version.
>   > > 
>   > > I can reproduce it with a version checked out this morning from CVS
>   > > trunk and one that is about 1 week old, I don't have anything older
>   > > than that. 
>   > > 
>   > > Is your version up to date?
>   > 
>   > Yes - just updated it this morning.
> 
> I don't have any other ideas of what to try...

I dunno either. If somebody can come up with a reproducible test then I
could try to see what is going on. 


> Not related to this, but could you please look at these byte compile
> warnings for viper-cmd.el?
> 
> In viper-next-line-carefully:
> viper-cmd.el:2792:19:Warning: `next-line' used from Lisp code
> That command is designed for interactive use only
> 
> In viper-next-line:
> viper-cmd.el:3091:41:Warning: `next-line' used from Lisp code
> That command is designed for interactive use only
> 
> In viper-previous-line:
> viper-cmd.el:3134:41:Warning: `previous-line' used from Lisp code
> That command is designed for interactive use only
> 
> Most similar warnings have been fixed in CVS, but for the above is not
> obvious what to do.

ok

> In end of data:
> viper-cmd.el:5099:1:Warning: the function `viper-heading-end' might
> not be defined at runtime.

No idea why the above shows up. Could it be a compiler bug?

> 
> This one is strange
> 
> 
> viper-cmd.el:5099:1:Warning: the following functions are not known to
> be defined: quail-input-method, quail-start-translation,
>     event-to-character,  character-to-event, viper-iconify, key-press-event-p, event-key,
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    These should be optimized out by the byte compiler.

No idea. The above are mostly XEmacs functions.

> Also viper-xemacs-p is about as long as (featurep 'emacs) and as
> readable. Why not replace it?  Most similar macros have been replaced
> in CVS.


I do not really care, but see no reason why waste time on this one.

Re: ediff and coding systems

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> CC: kifer@cs.sunysb.edu, eliz@gnu.org, emacs-devel@gnu.org
> Date: Mon, 22 Oct 2007 12:42:47 +0900
> 
>   read-coding-system("Select coding system (default mule-utf-8): " mule-utf-8)
>   select-safe-coding-system-interactively(1 5557 (utf-8 ....))
>   select-safe-coding-system(1 5557 nil nil "/tmp/fineDiffA155544eB")
>   write-region(1 5557 "/tmp/fineDiffA155544eB" nil no-message)
>   ediff-make-temp-file(#<buffer  *ediff-tmp*> "fineDiffA" "/tmp/fineDiffA155544eB")
>   ediff-make-fine-diffs(5 noforce)
>   ediff-install-fine-diff-if-necessary(5)
>   ediff-next-difference(1)
>   call-interactively(ediff-next-difference)
> 
> I don't know why ediff-make-temp-file is called, but perhaps
> it should call write-region while binding
> coding-system-for-write to `no-conversion' or `emacs-mule'.

Not a good idea, I'm afraid: those temporary files (or parts thereof)
will need to be read back, when `diff' finishes, so each one needs to
be in the original encoding, or else the diffs will be incorrect.
E.g., imagine two files with the same text, but different encodings: I
don't think we want ediff say that they compare identical.

Re: ediff and coding systems

[Michael Kifer]

> In article <200710211922.l9LJMQFX013338@oogie-boogie.ics.uci.edu>, Dan Nicolaescu <dann@ics.uci.edu> writes:
> 
> > Can anybody else reproduce it? I don't know much about coding systems,
> > so unfortunately I can't really debug this myself.
> 
> I can reproduce it when I run Emacs with LANG=C, and try to
> see the 5th (or 6th) different point where non-ASCII
> charaters exist.  The calling sequence of read-coding-system
> is this:
> 
>   read-coding-system("Select coding system (default mule-utf-8): " mule-utf-8)
>   select-safe-coding-system-interactively(1 5557 (utf-8 ....))
>   select-safe-coding-system(1 5557 nil nil "/tmp/fineDiffA155544eB")
>   write-region(1 5557 "/tmp/fineDiffA155544eB" nil no-message)
>   ediff-make-temp-file(#<buffer  *ediff-tmp*> "fineDiffA" "/tmp/fineDiffA155544eB")
>   ediff-make-fine-diffs(5 noforce)
>   ediff-install-fine-diff-if-necessary(5)
>   ediff-next-difference(1)
>   call-interactively(ediff-next-difference)
> 
> I don't know why ediff-make-temp-file is called, but perhaps
> it should call write-region while binding
> coding-system-for-write to `no-conversion' or `emacs-mule'.

I still cannot reproduce this, but ediff-make-temp-file has been changed on
Aug 19 to use the coding system of the buffer for the temp file created out
of that buffer. This was in order to fix some other problem. Forgot which
-- it was on this list. The coding system of the buffer seems to be the
right thing. It was 'no-conversion before, but had a problem because those
temp files are then read back and no-conversion was screwing things up.




> 
> ---
> Kenichi Handa
> handa@m17n.org
> 

Re: ediff and coding systems

[Kenichi Handa]

In article <uve8zu6f4.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > From: Kenichi Handa <handa@m17n.org>
> > CC: kifer@cs.sunysb.edu, eliz@gnu.org, emacs-devel@gnu.org
> > Date: Mon, 22 Oct 2007 12:42:47 +0900
> > 
> >   read-coding-system("Select coding system (default mule-utf-8): " mule-utf-8)
> >   select-safe-coding-system-interactively(1 5557 (utf-8 ....))
> >   select-safe-coding-system(1 5557 nil nil "/tmp/fineDiffA155544eB")
> >   write-region(1 5557 "/tmp/fineDiffA155544eB" nil no-message)
> >   ediff-make-temp-file(#<buffer  *ediff-tmp*> "fineDiffA" "/tmp/fineDiffA155544eB")
> >   ediff-make-fine-diffs(5 noforce)
> >   ediff-install-fine-diff-if-necessary(5)
> >   ediff-next-difference(1)
> >   call-interactively(ediff-next-difference)
> > 
> > I don't know why ediff-make-temp-file is called, but perhaps
> > it should call write-region while binding
> > coding-system-for-write to `no-conversion' or `emacs-mule'.

> Not a good idea, I'm afraid: those temporary files (or parts thereof)
> will need to be read back, when `diff' finishes, so each one needs to
> be in the original encoding, or else the diffs will be incorrect.
> E.g., imagine two files with the same text, but different encodings: I
> don't think we want ediff say that they compare identical.

Perhaps you are right.  I don't know what ediff is going to
write.

---
Kenichi Handa
handa@m17n.org

Re: ediff and coding systems

[Stefan Monnier]

> Not a good idea, I'm afraid: those temporary files (or parts thereof)
> will need to be read back, when `diff' finishes, so each one needs to
> be in the original encoding, or else the diffs will be incorrect.
> E.g., imagine two files with the same text, but different encodings: I
> don't think we want ediff say that they compare identical.

Quite the contrary: it's the only right thing to do because we're comparing
two pieces of buffer (not file), so we want to deal with *any* char (even
those that will not be savable in the current buffer-file-coding-system) and
both files that we pass to `diff' will be temporaily created by ediff
anyway so that will also ensure they both use the same encoding.


        Stefan

Re: ediff and coding systems

[Stefan Monnier]

> I still cannot reproduce this, but ediff-make-temp-file has been changed on
> Aug 19 to use the coding system of the buffer for the temp file created out
> of that buffer. This was in order to fix some other problem. Forgot which
> -- it was on this list. The coding system of the buffer seems to be the
> right thing. It was 'no-conversion before, but had a problem because those
> temp files are then read back and no-conversion was screwing things up.

`no-conversion' is a bad choice (it only works for unibyte data).  You want
`emacs-mule' (or rather `emacs-internal' but this one doesn't exist: I mean
by `emacs-internal' the encoding used internally, so it's `emacs-mule' in
Emacs22 but it will be different in Emacs23).


        Stefan

Re: ediff and coding systems

[Michael Kifer]

> > I still cannot reproduce this, but ediff-make-temp-file has been changed on
> > Aug 19 to use the coding system of the buffer for the temp file created out
> > of that buffer. This was in order to fix some other problem. Forgot which
> > -- it was on this list. The coding system of the buffer seems to be the
> > right thing. It was 'no-conversion before, but had a problem because those
> > temp files are then read back and no-conversion was screwing things up.
> 
> `no-conversion' is a bad choice (it only works for unibyte data).  You want
> `emacs-mule' (or rather `emacs-internal' but this one doesn't exist: I mean
> by `emacs-internal' the encoding used internally, so it's `emacs-mule' in
> Emacs22 but it will be different in Emacs23).

Right, no-conversion had problems. So, should I use emacs-mule for now
and do something else in Emacs23?

Re: ediff and coding systems

[Eli Zaretskii]

> Cc: Kenichi Handa <handa@m17n.org>,  dann@ics.uci.edu,  kifer@cs.sunysb.edu,
> 	  emacs-devel@gnu.org
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 22 Oct 2007 11:32:30 -0400
> 
> > Not a good idea, I'm afraid: those temporary files (or parts thereof)
> > will need to be read back, when `diff' finishes, so each one needs to
> > be in the original encoding, or else the diffs will be incorrect.
> > E.g., imagine two files with the same text, but different encodings: I
> > don't think we want ediff say that they compare identical.
> 
> Quite the contrary: it's the only right thing to do because we're comparing
> two pieces of buffer (not file)

I don't think ediff-make-temp-file knows that.  It's a general-purpose
utility function in ediff, AFAIR, and is invoked for files as well.

Note: I was responding to Handa-san's suggestion that
ediff-make-temp-file binds coding-system-for-write.

Re: ediff and coding systems

[Dan Nicolaescu]

kifer@cs.sunysb.edu (Michael Kifer) writes:

  > > kifer@cs.sunysb.edu (Michael Kifer) writes:
  > > 
  > >   > > kifer@cs.sunysb.edu (Michael Kifer) writes:
  > >   > > 
  > > This one is strange
  > > 
  > > 
  > > viper-cmd.el:5099:1:Warning: the following functions are not known to
  > > be defined: quail-input-method, quail-start-translation,
  > >     event-to-character,  character-to-event, viper-iconify, key-press-event-p, event-key,
  > >     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  > >    These should be optimized out by the byte compiler.
  > 
  > No idea. The above are mostly XEmacs functions.

These warnings show up because the XEmacs functions are conditionally
called with the condition being the viper-xemacs-p defconst. 
Defconsts cannot be optimized out at compile time.


  > > Also viper-xemacs-p is about as long as (featurep 'emacs) and as
  > > readable. Why not replace it?  Most similar macros have been replaced
  > > in CVS.
  > 
  > 
  > I do not really care, but see no reason why waste time on this one.

Would you mind if I do it? For viper* and ediff* ?  
Doing this will allow the byte compiler to get rid code at compile
time, this saves a few kilobytes of disk space.

Re: ediff and coding systems

[Michael Kifer]

> kifer@cs.sunysb.edu (Michael Kifer) writes:
> 
>   > > kifer@cs.sunysb.edu (Michael Kifer) writes:
>   > > 
>   > >   > > kifer@cs.sunysb.edu (Michael Kifer) writes:
>   > >   > > 
>   > > This one is strange
>   > > 
>   > > 
>   > > viper-cmd.el:5099:1:Warning: the following functions are not known to
>   > > be defined: quail-input-method, quail-start-translation,
>   > >     event-to-character,  character-to-event, viper-iconify, key-press-event-p, event-key,
>   > >     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   > >    These should be optimized out by the byte compiler.
>   > 
>   > No idea. The above are mostly XEmacs functions.
> 
> These warnings show up because the XEmacs functions are conditionally
> called with the condition being the viper-xemacs-p defconst. 
> Defconsts cannot be optimized out at compile time.
> 
> 
>   > > Also viper-xemacs-p is about as long as (featurep 'emacs) and as
>   > > readable. Why not replace it?  Most similar macros have been replaced
>   > > in CVS.
>   > 
>   > 
>   > I do not really care, but see no reason why waste time on this one.
> 
> Would you mind if I do it? For viper* and ediff* ?  

I do not mind, but I am doing some changes now and do not want conflicts to
arise. Hold off for a couple of weeks.

> Doing this will allow the byte compiler to get rid code at compile
> time, this saves a few kilobytes of disk space.

I claim that a few Kbs are not worth of anybody's time these days.