Re: (xslide) GNU Emacs

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

Thank you for trying my patch!  You have made me very happy.

> The cosmetic quibble that I have is with putting successive ')' on
> separate lines.  I do that myself in things like my own
> `vm-auto-folder-alist' in my .vm file when I have a list that I'm
> continually tweaking, but I think that xslide should follow the Emacs
> convention and put all the ')' together.

I'll quibble with you.  I find I understand the code quicker when the blocks are obviously visible and lined up in the same column.  If I have to position my cursor after every closing parentheis to find out which parenthesis I am closing it really slows me down.  I am self taught - I learned by rummaging through other's code.   Many times I have caught bugs in the code of better programmers than I (and worse) by simply indenting it neatly.

That said, you're the boss.  If I haven't convinced you, let me know
and I'll convert all my code to the standard outlined in the Emacs
Lisp Manual you cited.

> I was reading the Emacs Lisp manual last week (mostly because I was
> 
>    Don't make a habit of putting close-parentheses on lines by
>    themselves; Lisp programmers find this disconcerting. Once in a
>    while, when there is a sequence of many consecutive
>    close-parentheses, it may make sense to split the sequence in one
>    or two significant places.

"Disconcerting" is a vague evasion, not a persuasive argument.  I believe readibility is one of the cornerstones of bug-free, easily maintainable code.  Furthermore, I believe the three pillars of readibility to be (from most important to least):

1.) Proper indentation where the closing of a block lines up in the same column as the opening.

2.) Well thought out variable names.

3.) Documenting context.  The code itself ultimately says how it does what it does, but only a human can document the big picture of what the code is trying to accomplish and why it does it the way it does instead of some other way.

Again, this is your project.  You call the shots.  I'll state my opinion, but conform to whatever you like.  You got me on my soapbox with your quibble!

> 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'm glad you brought that up.  I actually have a prototype version that
uses an expanded version of the xsl-element-symbol-alist to do just that.
I could use your help.  In Java, C, or C++, you can create a data-type
where each element is labelled.  However, in Lisp, you just have lists.
Each variable is represented by an offset, or nested list element and I
know of no way to name these elements.  You can only document what data
and data-type to expect in each position in the comments.  That makes
it hideously tedious to deal with even moderatly complicated data
structures.

I stopped developing my list version of xsl-electric-space because I
thought that even if I succeeded, it would be unmaintainable and a
constant headache.  The way I have it implemented, while not elegant,
is easy to understand and maintain.

> The truth is that this is one of those things that I've always wanted
> to do but haven't, not least because I couldn't wrap my head around
> obarrays, `intern', `get', and `put', which is how I figured it should
> be done properly even while I couldn't grasp how to do it properly.

What's an obarray?  I've been using car, cdr, and such to traverse my
nested lists.  I can post my experiments as a patch if you like.

> 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?

The fringe benefit of creating such a list with some set and get
methods would be to auto-generate documentation for xsl, xsl-fo, and html elements and attributes.  Here's my data structure for storing
information about elements:

; Tag name
;   can be empty?
;   can have children?
;   required attributes list (each attribute a sub-list)
;     name
;     value list
;     default value
;     requires empty tag
;     list of other attributes this attribute requires
;   optional attribute (each a list: same as attributes above)
;   child name list (dotted pairs of name and regex: +, *, or "")

(list
  '("xsl:apply-imports" t nil
    '(nil)
    '(nil)
    '(nil)
  )
  '("xsl:apply-templates" t t
    '(nil)
    '(
      ("select" '(nil) nil t '(nil))
      ("mode" '(nil) nil nil '(nil))
    )
    '( ("xsl:sort" "*") ("xsl:with-param" "*") )
  )
  ...

Either way, it quickly becomes very complicated to see what's what.
In Java, one might write:

public class ElementInfo
{
   private String tagName = "";
   private boolean canBeEmpty = false;
   private boolean canHaveChildren = false
   private AttributeVector reqAttributes = null;
   private AttributeVector optAttributes = null;
   private Properties childNames = null;
}

Without any comments, it's obvious what's going on.  I haven't found
a simliar feature with Lisp.  Is there one?  If not, I would guess that's
the reason Lisp never had the popularity of C or C++: Data structures 
just get too confusing too fast.  Tell me I'm wrong.  I want to learn.
Can you reccomend a good book on ELisp or Lisp?

P.S.  I'm in a bit of a crunch time at work right now and I've had to put Emacs Lisp on the back burner.  Probably next week will be the same.

---
Glen Peterson
Senior Software Engineer, Web Consultant
South Hamilton, MA USA