format.el

format.el

[Richard Stallman]

format.el defines conversions for some international text representations
that are implented by running recode.  Also two that use iso-german
and iso-spanish.

Are these features still useful, or have they been obsoleted
by Mule facilities?  Can we delete some of this as obsolete?

Re: format.el

[Eli Zaretskii]

> Date: Sat, 6 Apr 2002 10:32:48 -0700 (MST)
> From: Richard Stallman <rms@gnu.org>
> 
> format.el defines conversions for some international text representations
> that are implented by running recode.  Also two that use iso-german
> and iso-spanish.
> 
> Are these features still useful, or have they been obsoleted
> by Mule facilities?  Can we delete some of this as obsolete?

AFAICS, the conversions that use `recode' can be rewritten to use
Emacs facilities based on Mule.  However, someone will have to write
more-or-less trivial wrappers for encode-coding-region and friends,
since we don't currently support encoding with names `ibm-pc',
`roman8', and iso646-ge.

As for iso-german and iso-spanish, they are imlpemented in iso-cvt.el.
I don't know what are the target encodings of those two, so I cannot
say whether Mule supports that.  Anybody?

Re: format.el

[Kai Großjohann]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> As for iso-german and iso-spanish, they are imlpemented in iso-cvt.el.
> I don't know what are the target encodings of those two, so I cannot
> say whether Mule supports that.  Anybody?

iso-german converts `"a' (two ascii chars) into `ä' (one latin-1
char), similar for ö and ü and their uppercase versions.  And then
there are `\3' and `"s' which are both converted into `ß'.

Hm.  Maybe this can also be expressed in Mule.  But I think there is
no predefined coding system for this.

kai
-- 
Silence is foo!

Re: format.el

[Richard Stallman]

    AFAICS, the conversions that use `recode' can be rewritten to use
    Emacs facilities based on Mule.  However, someone will have to write
    more-or-less trivial wrappers for encode-coding-region and friends,
    since we don't currently support encoding with names `ibm-pc',
    `roman8', and iso646-ge.

Is this assuming we are trying to maintain precise compatibility?  I
doubt that is necessary, since these interfaces are probably rarely
used.  I think we may as well recommend people invole the Mule
facilities directly.  If these facilities in format.el don't provide
any extra *functionality* then I think we may as well just delete
them.

Re: format.el

[Eli Zaretskii]

On Sun, 7 Apr 2002, Richard Stallman wrote:

>     AFAICS, the conversions that use `recode' can be rewritten to use
>     Emacs facilities based on Mule.  However, someone will have to write
>     more-or-less trivial wrappers for encode-coding-region and friends,
>     since we don't currently support encoding with names `ibm-pc',
>     `roman8', and iso646-ge.
> 
> Is this assuming we are trying to maintain precise compatibility?

Yes.

format.el

[Luc Teirlinck]

What about the following patch to format.el, which would make
`format-write-file' ask interactively for confirmation before
overwriting an existing file, in exactly the same way `write-file'
does?  I believe most users would expect `format-write-file' to behave
exactly like the more familiar and analogous `write-file' and asking
for confirmation does seem a lot safer.

The patch would also make `format-insert-file' always return a list of
two elements, just like `insert-file-contents' does, instead of
returning such a list if the FORMAT argument is nil and a non-list
cons cell otherwise.  There seems to be no reason whatsoever for the
subtle difference and I checked that the `insert-file-contents' change
does not produce any incompatibilities in the Emacs source code,
because the format argument is `nil' in all involved uses.  That is
exactly the case that would not change.

Those subtle differences can confuse the user and they would have to
be carefully documented at all appropriate places, including the Elisp
manual (currently that is not the case).  It seems a lot easier to
make the behavior uniform.

I could install if desired.

===File ~/format.el-diff====================================
*** format.el.~1.43.~	Mon Feb  9 13:59:35 2004
--- format.el	Mon Mar  8 20:07:30 2004
***************
*** 366,376 ****
  		 (funcall to-fn beg end (current-buffer)))))
  	  (setq format (cdr format)))))))
  
! (defun format-write-file (filename format)
    "Write current buffer into file FILENAME using some FORMAT.
! Makes buffer visit that file and sets the format as the default for future
  saves.  If the buffer is already visiting a file, you can specify a directory
! name as FILENAME, to write a file of the same old name in that directory."
    (interactive
     ;; Same interactive spec as write-file, plus format question.
     (let* ((file (if buffer-file-name
--- 366,380 ----
  		 (funcall to-fn beg end (current-buffer)))))
  	  (setq format (cdr format)))))))
  
! (defun format-write-file (filename format &optional confirm)
    "Write current buffer into file FILENAME using some FORMAT.
! Make buffer visit that file and set the format as the default for future
  saves.  If the buffer is already visiting a file, you can specify a directory
! name as FILENAME, to write a file of the same old name in that directory.
! 
! If optional third arg CONFIRM is non-nil, this function asks for
! confirmation before overwriting an existing file.  Interactively,
! confirmation is required unless you supply a prefix argument."
    (interactive
     ;; Same interactive spec as write-file, plus format question.
     (let* ((file (if buffer-file-name
***************
*** 382,388 ****
  				  nil nil (buffer-name))))
  	  (fmt (format-read (format "Write file `%s' in format: "
  				    (file-name-nondirectory file)))))
!      (list file fmt)))
    (let ((old-formats buffer-file-format)
  	preserve-formats)
      (dolist (fmt old-formats)
--- 386,392 ----
  				  nil nil (buffer-name))))
  	  (fmt (format-read (format "Write file `%s' in format: "
  				    (file-name-nondirectory file)))))
!      (list file fmt (not current-prefix-arg))))
    (let ((old-formats buffer-file-format)
  	preserve-formats)
      (dolist (fmt old-formats)
***************
*** 393,399 ****
      (dolist (fmt preserve-formats)
        (unless (memq fmt buffer-file-format)
  	(setq buffer-file-format (append buffer-file-format (list fmt))))))
!   (write-file filename))
  
  (defun format-find-file (filename format)
    "Find the file FILENAME using data format FORMAT.
--- 397,403 ----
      (dolist (fmt preserve-formats)
        (unless (memq fmt buffer-file-format)
  	(setq buffer-file-format (append buffer-file-format (list fmt))))))
!   (write-file filename confirm))
  
  (defun format-find-file (filename format)
    "Find the file FILENAME using data format FORMAT.
***************
*** 416,422 ****
  the part of the file to read.
  
  The return value is like the value of `insert-file-contents':
! a list (ABSOLUTE-FILE-NAME . SIZE)."
    (interactive
     ;; Same interactive spec as write-file, plus format question.
     (let* ((file (read-file-name "Find file: "))
--- 420,426 ----
  the part of the file to read.
  
  The return value is like the value of `insert-file-contents':
! a list (ABSOLUTE-FILE-NAME SIZE)."
    (interactive
     ;; Same interactive spec as write-file, plus format question.
     (let* ((file (read-file-name "Find file: "))
***************
*** 429,435 ****
        (setq size (nth 1 value)))
      (if format
  	(setq size (format-decode format size)
! 	      value (cons (car value) size)))
      value))
  
  (defun format-read (&optional prompt)
--- 433,439 ----
        (setq size (nth 1 value)))
      (if format
  	(setq size (format-decode format size)
! 	      value (list (car value) size)))
      value))
  
  (defun format-read (&optional prompt)
============================================================

Re: format.el

[Richard Stallman]

    The patch would also

In general, could you please submit independent changes separately,
not combined in a single patch?

Combining patches makes for difficulties.  Often the result is that
the patch is not installed because thinking about the separate issues
is too much trouble.  Perhaps there is no problem this time, but
please let's avoid developing a habit that so often causes problems.