emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs Lisp's future


From: David Kastrup
Subject: Re: Emacs Lisp's future
Date: Wed, 08 Oct 2014 17:54:46 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

Mark H Weaver <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>
>> Mark H Weaver <address@hidden> writes:
>>
>>> David Kastrup <address@hidden> writes:
>>>> You cannot successfully cater for clueless application programmers.
>>>
>>> It is not "clueless" to expect a UTF-8 encoder to produce valid UTF-8.
>>
>> We are not talking about "producing" but "reproducing" here.
>
> I stand by my statement above, regardless of what input is feed into the
> UTF-8 encoder, and I think I've said enough to make my point.  You are
> immovable, as always, and I don't want to waste any more time on this.

Shrug.  It's hard to move me when I have been around in similar
circumstances and when I've been been exposed to the consequences of
similar decisions before.

AUCTeX's prv-xemacs.el contains

(defcustom preview-buffer-recoding-alist
  (if (and (= emacs-major-version 21)
           (< emacs-minor-version 5))
      '((utf-8-unix . raw-text-unix)
        (utf-8-dos . raw-text-dos)
        (utf-8-mac . raw-text-mac)
        (utf-8 . raw-text)))
  "Translate buffer encodings into process encodings.
TeX is sometimes bad dealing with 8bit encodings and rather bad
dealing with multibyte encodings.  So the process encoding output
might need to get temporarily reprocessed into the original byte
stream before the buffer characters can be identified.  XEmacs
21.4 is rather bad at preserving incomplete multibyte characters
in that process.  This variable makes it possible to use a
reconstructable coding system in the run buffer instead.  Specify
an alist of base coding system names here, which you can get
using

  \(coding-system-name (coding-system-base buffer-file-coding-system))

in properly detected buffers."
  :group 'preview-latex
  :type '(repeat (cons symbol symbol)))

(defun preview-buffer-recode-system (base)
  "This is supposed to translate unrepresentable base encodings
 into something that can be used safely for byte streams in the
 run buffer.  XEmacs mule-ucs is so broken that this may be
 needed."
  (or (cdr (assq (coding-system-name base)
                 preview-buffer-recoding-alist))
      base))


as opposed to prv-emacs.el's

(defsubst preview-buffer-recode-system (base)
  "This is supposed to translate unrepresentable base encodings
into something that can be used safely for byte streams in the
run buffer.  A noop for Emacs."
  base)


What you don't see is the associated man-month of bug reports, hassles,
head-scratching, debugging, solution-finding, abstracting and boiling
down into a solution.


I've been at the receiving end of the "reproducing the input bytes
faithfully is not a priority" mindframe, and it is costly.  If I am
immovable here, it's because I'm old.  I've been a programmer long
enough in this game to know that "but when _we_ do that, everything will
be different" pans out rarely enough.

And it's not like I'm not getting bitten at the current point of time
while trying to get LilyPond (and thus C++ strings) play well with
GUILE2 without buying into massive conversion overhead and/or possible
column counting mismatches.

We write out PostScript code.  A mixture of material in Latin1, UTF16BE,
and binary.  We read in utf8 code and have a flex scanner working on
in-memory byte streams it shares with the GUILE reader interpreting it
in UTF-8.

It's not like I don't know what I am talking about here.

> You can add this to your long list of reasons why you consider me a
> bad maintainer for Guile.

To be honest, I was not even aware you were maintainer for GUILE.  There
are several committers to the stable/2.0 branch (and sometimes merging
from there to master), and there is Andy Wingo committing to master in
occasional spurts of commits of highly experimental character that are
not discussed on any public list.  While I am clueless about the
official roles of the various developers, the resulting workflows look
more evolved than designed.  I can hardly blame you for something that
you do not appear to have much choice in.  Many GNU maintainers are
sovereigns without subjects or a castle, mostly endowed with the power
to let the sun rise in the morning.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]