all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: kifer@cs.sunysb.edu (Michael Kifer)
To: Dan Nicolaescu <dann@ics.uci.edu>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
Subject: Re: ediff and coding systems
Date: Sun, 21 Oct 2007 23:50:09 -0400	[thread overview]
Message-ID: <22573.1193025009@cs.sunysb.edu> (raw)
In-Reply-To: Message from Dan Nicolaescu <dann@ics.uci.edu> of "Sun, 21 Oct 2007 19:08:39 PDT." <200710220208.l9M28dDG001750@oogie-boogie.ics.uci.edu>


> 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.

  reply	other threads:[~2007-10-22  3:50 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-20 15:21 ediff and coding systems Dan Nicolaescu
2007-10-20 18:09 ` Eli Zaretskii
2007-10-21  5:43   ` Michael Kifer
2007-10-21  6:12     ` Dan Nicolaescu
2007-10-21  6:52       ` Michael Kifer
2007-10-21  7:17         ` Dan Nicolaescu
2007-10-21 18:46           ` Michael Kifer
2007-10-21 19:22             ` Dan Nicolaescu
2007-10-21 19:37               ` Leo
2007-10-21 21:35               ` Michael Kifer
2007-10-22  2:08                 ` Dan Nicolaescu
2007-10-22  3:50                   ` Michael Kifer [this message]
2007-10-27 21:03                     ` Dan Nicolaescu
2007-10-28 21:01                       ` Michael Kifer
2007-10-22  3:42               ` Kenichi Handa
2007-10-22  4:20                 ` Eli Zaretskii
2007-10-22  5:05                   ` Kenichi Handa
2007-10-22 15:32                   ` Stefan Monnier
2007-10-22 21:11                     ` Eli Zaretskii
2007-10-22  4:29                 ` Michael Kifer
2007-10-22 15:34                   ` Stefan Monnier
2007-10-22 16:18                     ` Michael Kifer
2007-10-21  2:12 ` Stefan Monnier
2007-10-21  2:43   ` Dan Nicolaescu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=22573.1193025009@cs.sunysb.edu \
    --to=kifer@cs.sunysb.edu \
    --cc=dann@ics.uci.edu \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.