all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: rms@gnu.org
Cc: handa@m17n.org, emacs-devel@gnu.org
Subject: Re: insert-file-contents and format-decode
Date: Tue, 03 Jul 2007 08:43:45 +0200	[thread overview]
Message-ID: <4689F021.3050908@gmx.at> (raw)
In-Reply-To: <E1I5Zw7-0007fO-AF@fencepost.gnu.org>

 >     ! 	  /* Suppose replace is non-nil and we succeeded in not replacing the
 >     ! 	  beginning or end of the buffer text with the file's contents.  In this
 >     ! 	  case we neverthelss have to call format-decode with `point' positioned
 >     ! 	  at the beginning of the buffer
 >
 > I think that's a bug.  Point has to be at the beginning of the
 > inserted text.  If you put it at the beginning of the buffer,
 > the decoding functions have no way to determine what text
 > was just inserted, so they can't possibly do the job.

I don't understand: Fixing this was my primary intention (where
"beginning of the buffer" should read "beginning of the accessible
portion of the buffer" though in practice this is needed only for
`revert-buffer').  That's what the "replace" stuff is all about.  In the
particular case the decoding functions should be fooled into believing
that more text was inserted from the file.

 > The same goes for the Vafter_insert_file_functions.
 > It is the only way to make that case work.

These are done for the replace non-nil case only.  Both `format-decode'
and `after-insert-file-functions' were inherently broken in that case.

 > If that conflicts with documentation, then the documentation
 > has to be corrected.

There's no specific documentation on that.  `format-decode' and
`after-insert-file-functions' simply ceased to work correctly after the
`insert-file-contents' optimizations for the replace non-nil case were
installed.

 >
 >     !       else
 >     ! 	/* In the visiting case restore the previous value. */
 >     ! 	current_buffer->undo_list = old_undo;
 >
 > When visiting a file, you should set undo_list to t
 > if it was t before, otherwise to nil.
 >

I believed an earlier comment here that read as

       /* If we're anyway going to discard undo information, don't
	 record it in the first place.  The buffer's undo list at this
	 point is either nil or t when visiting a file.  */

Hence my

 >     ! 	current_buffer->undo_list = old_undo;

should have done that automatically.  Is it better to rewrite as:

       if (NILP (visit))
	{
	  ...
	}
       else if (old_undo == Qt)
	/* If undo_list was Qt before, keep it that way. */
	current_buffer->undo_list = Qt;
       else
	/* Otherwise start with an empty undo_list. */
	current_buffer->undo_list = Qnil;

  reply	other threads:[~2007-07-03  6:43 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-06 14:06 insert-file-contents and format-decode martin rudalics
2007-06-08  7:12 ` Richard Stallman
2007-06-17 13:34   ` martin rudalics
2007-06-18 21:31     ` Richard Stallman
2007-06-19  7:50       ` martin rudalics
2007-06-23 18:26         ` Richard Stallman
2007-06-23 18:26         ` Richard Stallman
2007-06-24 10:30           ` martin rudalics
2007-06-25 13:19             ` Richard Stallman
2007-06-26  6:54               ` martin rudalics
2007-06-26 22:48                 ` Richard Stallman
2007-06-27  6:33                   ` martin rudalics
2007-06-27 19:50                     ` Richard Stallman
2007-06-30 11:11                       ` martin rudalics
2007-07-01  0:30                         ` Richard Stallman
2007-07-02  8:14                           ` martin rudalics
2007-07-03  4:24                             ` Richard Stallman
2007-07-03  6:47                               ` martin rudalics
2007-07-04  3:43                                 ` Richard Stallman
2007-06-26 22:48                 ` Richard Stallman
2007-06-27  6:34                   ` martin rudalics
2007-06-27 23:43                     ` Richard Stallman
2007-06-30 11:32                       ` martin rudalics
2007-07-01  0:30                         ` Richard Stallman
2007-07-02  8:27                           ` martin rudalics
2007-07-03  4:24                             ` Richard Stallman
2007-07-03  6:43                               ` martin rudalics [this message]
2007-08-06 14:22                                 ` Richard Stallman

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=4689F021.3050908@gmx.at \
    --to=rudalics@gmx.at \
    --cc=emacs-devel@gnu.org \
    --cc=handa@m17n.org \
    --cc=rms@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.