emacs-devel
[Top][All Lists]
Advanced

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

Re: Emacs vista build failures


From: Barry Fishman
Subject: Re: Emacs vista build failures
Date: Mon, 28 Jul 2008 21:00:19 -0400
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (gnu/linux)

Richard M Stallman <address@hidden> writes:
>     For example, one should ultimately be able to do things like have
>     GnuCash use Emacs/TTY code to display in text windows.
>
> It is a useful goal.  Do you want to work on trying to design a way to
> do this?  Preferably it should not involve linking parts of Emacs with
> GNUcash.  Too unmodular.  Better to have them communicate somehow.

It is a matter of where you draw the module boundaries.  Right now
GNUcash uses Guile, GTK, and some application specific lisp and lower
level C code.  Emacs uses (I guess) its own ELisp, buffers, GTK (among
other possibilities) under Emacs's rendering code and application
specific Lisp and lower level C code.

>From what I understand, Emacs will be moving to Guile (or at least a
Guile updated to meet its needs).  If GTK is integrated and updated in a
way that supports frames and buffers, and allow for a similar objects
for TTY frames and buffers, a merge of GNUcash and Emacs becomes more
like a bit of a lisp based connective code, to let GNUcash use TTY
frames/windows instead of GTK ones.

Does integration of Emacs into the GNU Desktop mean that Emacs just
starts picking up Gnome and dbus facilities, and dropping portability
concerns, or does it becomes a source of components and ideas that can
be used in other applications.  Otherwise I am afraid that the "make GNU
look like Windows" people will bury us in the sort of fragile C++
monoliths like Firefox, that leave most everyone out.

I think freedom is not just having source, and the permission to make
changes and distribute them.  Its also about it being straightforward to
actually modify applications in ways that are useful.  Emacs is excellent
at this.  I must have thousands of lines of elisp code, of probably no
interest to anyone else, that I have written to tune simple Emacs
features.  One can easily make changes where the authors did not allow
for them (without maintaining patches to the original sources):

;; FQDN patch - Force smtpmail to use mail-host-address
(autoload 'smtpmail-fqdn "smtpmail" nil nil)
(defadvice smtpmail-fqdn (around change-smtpmail-fqdn activate)
  "Supply a domain which is meaningful but wrong"
  (setq ad-return-value mail-host-address))
(setq message-user-fqdn mail-host-address)

-- 
Barry Fishman




reply via email to

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