Re: (xslide) GNU Emacs

[Glen P. <gl...@or...>]

On Wed, 2003-06-18 at 21:56, Tony Graham wrote:
>  > > The part that I do want to work on is the part of `xsl-electric-space'
>  > > that adds required attributes.  I would rather not put the logic in
>  > > the code, and I would like to think that `xsl-element-symbol-alist' in
>  > > xslide-data.el has the raw material for going it by lookup.

> I have noticed, however, that Emacs 21 has hash tables, which may also
> be useful for part of this.
> 

I imagine hash-tables are slower than indexing vectors or arrays because
you have to compare against each hash before finding the one you want. 
By the time we add support for xsl, xslfo, html, and whatever other
group of element and attribute names, this could become a problem. 
Plus, if we are going to make an elegant solution, I'd rather make a
macro to create get and set methods that access offsets into arrays or
Vectors.

I asked a lisp hacker about this and he told me to check out defstruct. 
My initial experiments show it to be interesting.  This lisp hacker
brightened when I told him my question was for xslide.  He said that he
uses it in XEmacs even to edit html and really likes it.  Good work Tony
and friends!

>  > > So, do you (all of you) want to work with me on putting
>  > > `xsl-element-symbol-alist' (or its successor) to its intended use?
>  > 
>  > Back to my previous point, what do you hope to achieve by doing so?
>  > Gain functionality?  Maintainability?  Or just to learn cool lisp stuff
>  > and create an interesting and elegant solution to a problem?
> 
> Maintainability, functionality, and extensibility.
> 
> If the data is in xslide-data.el (or similar) then you can slice it
> and dice it multiple ways.  For example, the stuff in xslide-data.el
> is currently used in `xsl-complete', `xsl-insert-tag',
> `xsl-font-lock-keywords', and `xsl-mode-abbrev-table'.  That seems to
> me to be better than repeating the same information in multiple
> places.

The more I think about it, the more I think you're right.  Plus, I can't
think of anything better to do for 50 minutes on the train each morning
and evening.  :-)

> One of the requests I had a long time ago was to support the same sort
> of block/inline/empty differences with `xsl-insert-tag' but with
> arbitrary tag sets.  I would, therefore, like to get to the point that
> the element and attribute information is something that you can use
> 'Customize' on so that any user can add another tag set.  (I'd really
> like to just import a DTD or other schema, but one thing at a time.)

Customize is a good idea.  I had also imagined being able to hit f1 when
your cursor is on a tag and get a help window describing that tag -
basically by parsing the same data structure that describes everything
about these tags, and putting some plain English text around it.  I
actually have a prototype working.

> Pretty soon xslide will need to be extended to support XSLT 2.0.

That would be much easier with the data separate from the code.  Another
point for your suggestion.

> Actually, I'd like to move to using the semantic bovinator for a lot
> of this, but I don't have time to delve into it myself.

bovinator?  I'm skeptical.  I'm having too much fun writing the lisp by
hand right now anyway.

I have to raise one other thought.  Xslide isn't exactly the hottest
project on source-forge.  My understanding of the Open Source is that it
harnesses the power of community sometimes at the expense of breaking
the rules of successful software development.  And if Linux is any
example, it can be at least an even trade.

Would it be to our advantage to consider scaling the development effort
on this project?  Have you ever considered merging with sgml-mode?  How
far will "If it's good, people will use it" take us?  What happened to
all the other people whose names are in the source code?  These are more
honest questions than suggestions for me right now.

-Glen