all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Werner LEMBERG <wl@gnu.org>
Cc: 8108@debbugs.gnu.org
Subject: bug#8108: 24.0.50; debugging pre-write-conversion in define-coding-system
Date: Thu, 21 Apr 2011 12:06:40 +0300	[thread overview]
Message-ID: <83ipu82ctb.fsf@gnu.org> (raw)
In-Reply-To: <20110421.074819.360562129.wl@gnu.org>

> Date: Thu, 21 Apr 2011 07:48:19 +0200 (CEST)
> From: Werner LEMBERG <wl@gnu.org>
> 
> 
> Any takers?

I don't know enough about Edebug to help you understand why it doesn't
get activated.  However, if you can tell which version of Emacs was
last that did invoke the debugger, I could try looking for the changes
that could have caused that.  E.g., does that work in Emacs 23.x?

> The very problem is that cjk-enc.el, after being adapted
> to define-coding-system, completely fails: I no longer get any
> reasonable output, and all CJK characters disappear in the output.
> But without being able to debug I can't tell what and where exactly it
> is failing...

Are you comfortable with debugging on the C level, or does the
solution have to be on the Lisp level?

If the former, it looks like the pre-write-conversion function is
invoked in this fragment from encode_coding_object:

	args[0] = CODING_ATTR_PRE_WRITE (attrs);
	args[1] = make_number (BEG);
	args[2] = make_number (Z);
	safe_call (3, args);

By stepping into the safe_call function, then into Funcall that it
calls, you should be able to see how the Lisp interpreter runs the
code of you pre-write-conversion function and where it fails.  It is
less convenient than debugging in Lisp, but you still should be able
to display all the forms that are being evaluated, show the Lisp
backtrace with "xbacktrace", and even step into C-level primitives you
invoke from your pre-write-conversion function, something you cannot
do from Lisp.

Alternatively, maybe post here the code of your pre-write-conversion
function, perhaps someone will be able to find the problem just by
looking at the code.





  reply	other threads:[~2011-04-21  9:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-24  7:40 bug#8108: 24.0.50; debugging pre-write-conversion in define-coding-system Werner LEMBERG
2011-04-21  5:48 ` Werner LEMBERG
2011-04-21  9:06   ` Eli Zaretskii [this message]
2011-12-26 20:03     ` Werner LEMBERG
2011-12-27  3:52       ` Eli Zaretskii
2016-12-10 15:12 ` npostavs
2016-12-10 17:44   ` Werner LEMBERG

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=83ipu82ctb.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=8108@debbugs.gnu.org \
    --cc=wl@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.