[Openmcl-devel] A question about ticket #400
ron at awun.net
Mon Jun 22 18:46:56 UTC 2009
IMHO, it's a mistake to put code in files at all, especially Lisp
code. Lisp code isn't text, it's a data structure. It belongs in a
database, not a file. The idea that code consists of lines of text is
a leftover from the days when code resided on punched cards.
On Jun 22, 2009, at 10:50 AM, Dan Weinreb wrote:
> Any approach that involves storing data in a separate file
> runs into problems when someone tries to move the file,
> rename the file, mail the file, back up the file, compress
> the file, put the file into an archive file, and so on.
> -- Dan
> Glen Foy wrote:
>> On Jun 20, 2009, at 12:44 PM, Gail Zacharias wrote:
>>> Yeah, here's the thing... The API can easily provide any number of
>>> functions such as save/load-buffer-as-html or save/load-buffer-as-
>>> rtf or save/load-buffer-in-home-baked-format-with-font-info-encoded-
>>> in-lisp-comments or whatever, stuff like that would be trivial to
>>> write. The problem is that it's not clear to me what Hemlock should
>>> actually do to save the attributes, given the reality of living in a
>>> unix file system. Any thoughts?
>> If we are just talking about Hemlock as a source code editor, it may
>> not be necessary or even desirable to distribute styled files.
>> Everyone has their own idea of what source code should look like
>> From that point of view, the styling information could be stored in
>> an associated invisible file and distributed or not distributed as
>> author saw fit. When hacking, Hemlock would look for the associated
>> file, using it if it was there. This would be a simple solution.
>> People may, however, want to use Hemlock for other purposes. In
>> case the two file approach is not so good.
>> This issue clearly needs some brainstorming.
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openmcl-devel