xslide-list — Discussion list for xslide XSL mode for Emacs

Re: (xslide) tab-stops vs. tab-width

[xslide S. <xsl...@me...>]

At 8 Aug 2003 08:52 -0400, Glen Peterson wrote:
 > Last night I discovered I could query the local symbol table and add symbols without causing errors as follows:
 > 
 > (if (assoc 'beano (buffer-local-variables))

(if (local-variable-p 'beano)

saves knowing how it's implemented.

...
 > I used my new knowledge to fix one XEmacs compilation problem.  I put
 > 
 > (make-variable-buffer-local 'font-lock-mark-block-function)
 > 
 > above xsl-mode so that it would get compiled before the function and it seems to work.

But if 'font-lock-mark-block-function doesn't mean anything for
font-lock in XEmacs, I'd rather not set the variable at all in
XEmacs.  That is what the current code is supposed to be doing (or not
doing, in this case).

 > I tried implementing Tony's idea about calculating tab-stop-list
 > based on xsl-tab-width, but it seems that tab-stop-list is global
 > in a way that I haven't been able to set locally.  I mean, I can
 > set it without getting an error, but setting it doesn't change it's
 > value.  Evaluate these four expressions to see what I mean:

Executing this in *scratch*

 > (make-variable-buffer-local 'tab-stop-list)

followed by:

(local-variable-if-set-p 'tab-stop-list (current-buffer))

returns 't' in both Emacs and XEmacs.

 > (setq tab-stop-list (let ( (idx 1)
 >                            (lst ()))
 >                       (while (< idx 70)
 >                         (setq idx (+ idx tab-width))
 >                         (setq lst (append lst (list idx))))
 >                       lst)
 > 
 > (assoc 'tab-stop-list (buffer-local-variables))
 > 
 > tab-stop-list
 > 
 > I really like Tony's idea of calculating tab-stop-list based on
 > xsl-tab-width (which in turn is based on tab-width unless it has
 > been customized).  Any thoughts on how to make it work?

I got the idea from postscript.el in XEmacs.

The attached patch appears to work, but indent-tabs is still pretty
foreign to me.

Regards,


Tony Graham.

(xslide) xslide 0.2.2 released

[xslide S. <xsl...@me...>]

xslide 0.2.2 is now available on SourceForge:
http://sourceforge.net/projects/xslide/

The next step is to add more of Glen's additions and make a new
release of xslide.

Regards,


Tony Graham.

(xslide) xslide and speedbar

[xslide S. <xsl...@me...>]

I have discovered, to my intense pleasure, that xslide works well with
speedbar once you register the .xsl extension with speedbar.

Put:

   (require 'speedbar)

up with the other requires in xslide.el, then put:

   (speedbar-add-supported-extension (list ".xsl" ".fo"))

in the definition for `xsl-mode' (FWIW, I put it on line 1052), then
re-byte-compile, restart emacs, or whatever you need to do to get
emacs to notice the change.

When you're editing an XSL file, select 'Display speedbar' from the
'Tools' menu, and when you expand the entry for an XSL file, you'll
see the same entries as on the 'Templates' menu.

Some versions of speedbar do have problems with '*' patterns, since
'*' is also used in speedbar to indicate that the file is under
version control, and problems with patterns containing quotes,
e.g. "element[@att='value']" shows as ']' in speedbar.  However, I do
think its cool to be able to see templates from multiple files.

I also really like the "Emacs Code Browser" (from the author of
speedbar) which is at http://ecb.sourceforge.net/.  The ECB really
puts the 'ide' in 'xslide' (once speedbar support in enabled).

Regards,


Tony Graham.

Re: (xslide) tab-stops vs. tab-width

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

Last night I discovered I could query the local symbol table and add symbols without causing errors as follows:

(if (assoc 'beano (buffer-local-variables))
    beano
    (make-variable-buffer-local 'beano)
    (setq beano 17))

buffer-local-variables is a dotted-pair list of symbols and values.  Assoc tests to see if our *quoted* symbol (so it will work even if this symbol is not yet defined) is in the list.  If it is, we can use it.  If not, we can put it in the list.

I used my new knowledge to fix one XEmacs compilation problem.  I put

(make-variable-buffer-local 'font-lock-mark-block-function)

above xsl-mode so that it would get compiled before the function and it seems to work.

I tried implementing Tony's idea about calculating tab-stop-list based on xsl-tab-width, but it seems that tab-stop-list is global in a way that I haven't been able to set locally.  I mean, I can set it without getting an error, but setting it doesn't change it's value.  Evaluate these four expressions to see what I mean:

(make-variable-buffer-local 'tab-stop-list)

(setq tab-stop-list (let ( (idx 1)
                           (lst ()))
                      (while (< idx 70)
                        (setq idx (+ idx tab-width))
                        (setq lst (append lst (list idx))))
                      lst)

(assoc 'tab-stop-list (buffer-local-variables))

tab-stop-list

I really like Tony's idea of calculating tab-stop-list based on xsl-tab-width (which in turn is based on tab-width unless it has been customized).  Any thoughts on how to make it work?

-Glen

Re: (xslide) tab-stops vs. tab-width

[xslide S. <xsl...@me...>]

At 15 Jul 2003 11:26 -0400, xslide Support wrote:
 > Here's a plan:

Here's a second plan:

(defcustom xsl-indent-tabs-mode nil

   One of:

    - nil -- Indentation can't insert tabs

    - t -- Indentation can insert tabs

(defcustom xsl-indent-tabs-mode-p nil

   New (because I couldn't bring myself to add a third value to
   `xsl-indent-tabs-mode').  One of:

    - nil -- Is not local.  Do not make a local `indent-tabs-mode'

    - t -- Is local.  Set for current buffer

(defcustom xsl-element-indent-step 2

   Renamed back to original name since probably set under that name in
   lots of .emacs files.  One of:

    - nil -- Use `xsl-tab-width'

    - integer -- Number of columns to indent

(defcustom xsl-tab-width

   New.  One of:

    - nil -- Use `tab-width' (default)

    - integer -- Tab width to use

(defun xsl-compute-tab-stop-list (use-tab-width)
  ;; make a list of integers
  )

In `xsl-mode':

   (if xsl-indent-tabs-mode-p
     (setq indent-tabs-mode xsl-indent-tabs-mode))
   (if xsl-tab-width
       (progn
          (setq tab-width xsl-tab-width)
          (make-local-variable 'tab-stop-list)
          (setq tab-stop-list (xsl-compute-tab-stop-list xsl-tab-width))))

Regards,


Tony Graham.

Re: (xslide) tab-stops vs. tab-width

[xslide S. <xsl...@me...>]

At 15 Jul 2003 23:08 -0400, Glen Peterson wrote:
 > On Tue, 2003-07-15 at 11:26, xslide Support wrote:
 > > Here's a plan:
 > > 
 > > (defcustom xsl-indent-step 2
 > 
 > I like everything you suggest but I have 2 questions.
 > 
 > 1.) Why do we need a separate xsl-tab-width and xsl-tab-indent-step?  

I was starting to wonder that myself.  And, since you are a
`tab-stop-list' user, I was hoping you'd say something about it.  You
did.  Thank you.

I stuck it in the email message at the last minute since I figured
that people might have tab-stop widths that are different from the
indent step, but since then I've figured that probably isn't the
case.  However, since I don't fiddle with `tab-stop-list', both
conclusions are just guesses.

Since I think it's superfluous and you question it's necessity, it
probably should be removed.

 > 2.) Can we inherit default values from global variables where
 > appropriate.  If I use 3-space indentation, I would like that to be my
 > default for any mode unless I set it explicitly for that mode.  Same for
 > indent-tabs-mode.

The previous message did that for `tab-stop-list' but not for
`indent-tabs-mode'.  Obviously it should have.

The interesting thing about `indent-tabs-mode' is it's two values are
nil and non-nil.  Presumably we can define one, special non-nil value
of `xsl-indent-tabs-mode' as the indication to not set
`indent-tabs-mode' for the current buffer, rather like the `xsl-mode'
code for `tab-stop-list' in my previous post.

 > How do you make one variable inherit from another that may or not be
 > defined?  Is there any way to check to see if a variable is defined?  If
 > so, here's some pseudo code that shows an inheriting variation on what
 > you propose:

There are ways to check if a variable is defined, but I don't know how
to `defcustom' an undefined variable, so I don't think I could
implement your pseudo-code and let users use Customize to set the
variables if they want.

Also, `tab-width' is never going to be undefined.

...
 > Having an xsl-tab-stop-list separate from the global tab-stop-list is a
 > nice feature, but it's so far ahead of other emacs modes (many of which
 > don't support tabs at all) that I'm not sure it's necessary.

As I posted before, I grepped the .el files for Emacs and XEmacs, and
I most liked the `tab-stop-list' support in postscript.el from
XEmacs.  It does what I had been thinking of doing: generating
`tab-stop-list' from a tab width, which seems preferable to having to
enter the list by hand.

I did think that what I was suggesting was inline with Glen's earlier
musing, but when I did go back and look at his comments, it seems that
I got it completely backwards:

At 5 Jul 2003 12:56 -0400, Glen Peterson wrote:
 | Hmm... A better solution might be to make xsl-element-indent-step
 | inherit from tab-width if xsl-element-indent-step is not set.  That way
 | people will get the same indentation they use for other languages by
 | default, but they can change it if they want to.  What do you think? 
 | Whatever we decide, we might want to do something similar with
 | xsl-element-indent-step.

I had `xsl-indent-step' setting `xsl-tab-width', but Glen suggested
having `tab-width' setting `xsl-indent-step'.

Maybe `xsl-indent-step' could have a value that says derive from
`xsl-tab-width', which could derive from `tab-width'.

 > > Once this is implemented, it would probably be a good time to look at
 > > implementing reading and writing local variable definitions in the XSL
 > > files so you get rational-looking files when you open a stylesheet
 > > written by somebody with very different settings for these variables.
 > 
 > If indent-tabs-mode is nil, style sheets will look the same on every
 > system.  If indent-tabs-mode is t, the structure will be the same, but
 > the size of the indent may be different (like smaller or larger stair
 > steps).  The above statements are true so long as tabs and spaces are
 > not mixed in the same file.
 >
 > Either of these effects are (in my opinion) desirable.  Spaces look the
 > same on all systems.  Tabs let everyone see the file with their own
 > favorite indentation step width.  Tabs are also sometimes used to reduce
 > file sizes, but there is rarely a significant savings.  Neither of these
 > paradigms requires that extra display information be stored in the file.

If you expect an indent step of two characters and you get an indent
step of eight characters, you won't find it very desirable.  If you're
not a `tab-stop-list' practitioner, your favourite indentation step
width has little in common with your tab width.

Regards,


Tony Graham.

Re: (xslide) tab-stops vs. tab-width

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

On Tue, 2003-07-15 at 11:26, xslide Support wrote:
> Here's a plan:
> 
> (defcustom xsl-indent-step 2

I like everything you suggest but I have 2 questions.

1.) Why do we need a separate xsl-tab-width and xsl-tab-indent-step?  

2.) Can we inherit default values from global variables where
appropriate.  If I use 3-space indentation, I would like that to be my
default for any mode unless I set it explicitly for that mode.  Same for
indent-tabs-mode.

How do you make one variable inherit from another that may or not be
defined?  Is there any way to check to see if a variable is defined?  If
so, here's some pseudo code that shows an inheriting variation on what
you propose:

if xsl-tab-width is undefined
   if tab-width is defined
      setq xsl-tab-width tab-width
   else
      setq xsl-tab-width 2 (2 is the current default)

if xsl-indent-tabs-mode is undefined
   if indent-tabs-mode is defined
      setq xsl-indent-tabs-mode indent-tabs-mode
   else
      setq xsl-indent-tabs-mode nil (nil is the current default)

if xsl-tab-stop-list is undefined
   if tab-stop-list is defined
      setq xsl-tab-stop-list tab-stop-list (is this wise?)
   else
      generate xsl-tab-stop-list from xsl-tab-width

Then set local variables to the xsl- ones.

Having an xsl-tab-stop-list separate from the global tab-stop-list is a
nice feature, but it's so far ahead of other emacs modes (many of which
don't support tabs at all) that I'm not sure it's necessary.

> Once this is implemented, it would probably be a good time to look at
> implementing reading and writing local variable definitions in the XSL
> files so you get rational-looking files when you open a stylesheet
> written by somebody with very different settings for these variables.

If indent-tabs-mode is nil, style sheets will look the same on every
system.  If indent-tabs-mode is t, the structure will be the same, but
the size of the indent may be different (like smaller or larger stair
steps).  The above statements are true so long as tabs and spaces are
not mixed in the same file.

Either of these effects are (in my opinion) desirable.  Spaces look the
same on all systems.  Tabs let everyone see the file with their own
favorite indentation step width.  Tabs are also sometimes used to reduce
file sizes, but there is rarely a significant savings.  Neither of these
paradigms requires that extra display information be stored in the file.

Mixing tabs and spaces only looks right if the author and reader have
exactly the same tab-stops set.  I've been thinking about one way to mix
tabs and spaces that might look right on everyone's system but the
explanation is rather lengthy and I'm not absolutely certain it would
work in all cases, so you'll have to ask me about it if you are
interested.  It might be better to avoid this situation altogether than
to embed emacs-specific display information in xsl files.

-Glen

Re: (xslide) tab-stops vs. tab-width

[xslide S. <xsl...@me...>]

At 13 Jul 2003 22:37 -0400, xslide Support wrote:
 > I like what I see in postscript.el from the XEmacs distribution.  When
 > I get a chance, I'll compare that with what Glen has done.

Here's a plan:

(defcustom xsl-indent-tabs-mode nil

   Behaves as it does in xslide 0.2.

(defcustom xsl-indent-step 2

   Renamed from xsl-element-indent-step

   If `xsl-tab-width' is 'xsl-indent-step, then set `xsl-tab-width'
   (or similar-named variable) when `xsl-indent-step' changes.

(defcustom xsl-tab-width

   New.  Either an integer (default: 8) or 'xsl-indent-step, which
   means use `xsl-indent-step'.

   If `xsl-tab-stop-list' is 'xsl-tab-width, then recompute
   `xsl-tab-stop-list' (or similar-named variable) if `xsl-tab-width'
   changes.

(defcustom xsl-tab-stop-list

   New. One of:

    - 'global -- Use the global tab-stop-list (default)

    - 'xsl-tab-width -- Compute it based on `xsl-tab-width'

    - list -- Make your own list of integers

  If `xsl-tab-stop-list' is set to 'xsl-tab-width, then recompute
  `xsl-tab-stop-list' (or similar-named variable) based on
  `xsl-tab-width'.


In `xsl-mode':

   (setq indent-tabs-mode xsl-indent-tabs-mode)
   (if (not (eq xsl-tab-stop-list 'global))
       (progn
          (make-local-variable 'tab-stop-list)
          (setq tab-stop-list xsl-tab-stop-list)))


This will require some :set, :get, :initialize, and :set-after magic
in the `defcustom' definitions, but it should be doable.

Once this is implemented, it would probably be a good time to look at
implementing reading and writing local variable definitions in the XSL
files so you get rational-looking files when you open a stylesheet
written by somebody with very different settings for these variables.

Regards,


Tony Graham.

Re: (xslide) tab-stops vs. tab-width

[xslide S. <xsl...@me...>]

At 5 Jul 2003 22:51 -0400, xslide Support wrote:
 > Hassle me if I don't comment more on this within a week, but the
 > others on this list are welcome to chime in as well.

The computer with my copy of Glen's version isn't available right now,
but I grepped for tab-stop-list in both Emacs and XEmacs .el files.

I like what I see in postscript.el from the XEmacs distribution.  When
I get a chance, I'll compare that with what Glen has done.

Regards,


Tony Graham.

Re: (xslide) CVS checkin

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

On Wed, 2003-07-02 at 22:14, Tony wrote:
> I've checked in a revised xslide.el.  The significant difference is
> the addition of Glen's `xsl-if-to-choose', which worked fine when I
> tried it (although I wouldn't mind if you didn't have to be on the
> <xsl:if> tag, just inside it, for it to work).

One implication of having xsl-if-to-choose work anywhere inside the "if"
concerns me.  Imagine the case where you are inside a huge if block
where the <if> and </if> are both off the page.  I doubt most users
would be happy if they hit the xsl-if-to-choose key by mistake in this
circumstance.  That's why I'm not rushing to make a change.

-Glen

Re: (xslide) tab-stops vs. tab-width

[xslide S. <xsl...@me...>]

At 5 Jul 2003 12:56 -0400, Glen Peterson wrote:
 > >  | There is some good stuff there, plus some stuff that we'll need to
 > >  | work on.  Naturally I like `xsl-if-to-choose', but I'll need to be
 > >  | convinced why xslide needs a separate tab-stop mechanism from
 > >  | tab-width.
 > 
 > Sorry for taking so long to get back to you all.  Sometimes the
 > important points get lost in the noise.
 > 
 > Well, I could take this two ways.  I'll try to address both of them.

You've given me stuff to think about, since I've never played with
`tab-stop-list' and have always been happy with eight-column tab
stops.

Most of the variables that you mention become buffer-local as soon as
they're set, and it's easy to surmise that they're set up that way
just so that different modes can do different things.

Hassle me if I don't comment more on this within a week, but the
others on this list are welcome to chime in as well.

Regards,


Tony Graham.

(xslide) tab-stops vs. tab-width

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

>  | There is some good stuff there, plus some stuff that we'll need to
>  | work on.  Naturally I like `xsl-if-to-choose', but I'll need to be
>  | convinced why xslide needs a separate tab-stop mechanism from
>  | tab-width.

Sorry for taking so long to get back to you all.  Sometimes the
important points get lost in the noise.

Well, I could take this two ways.  I'll try to address both of them.

1.) tab-width controls how many space characters to insert when the tab
key is pressed and indent-tabs-mode is nil.  It has no effect when
indent-tabs-mode is t.  Therefore, if someone (such as myself) needs to
indent with tab characters, tab-width is irrelevant to them.  What
controls the width of the tab characters as they display on the screen
is the tab-stop-list variable.  I have performed several tests in XEmacs
to verify this but it's possible I missed something.

2.) Why a separate tab-width for xsl?  I like to indent my lisp code
with 2 space characters, but my xsl with three-space-wide tab
characters.  I thought it would be a nice feature to allow users to
indent each programming language differently.

Hmm... A better solution might be to make xsl-element-indent-step
inherit from tab-width if xsl-element-indent-step is not set.  That way
people will get the same indentation they use for other languages by
default, but they can change it if they want to.  What do you think? 
Whatever we decide, we might want to do something similar with
xsl-element-indent-step.

-Glen

(xslide) CVS checkin

[xslide S. <xsl...@me...>]

I've checked in a revised xslide.el.  The significant difference is
the addition of Glen's `xsl-if-to-choose', which worked fine when I
tried it (although I wouldn't mind if you didn't have to be on the
<xsl:if> tag, just inside it, for it to work).

I also put a `condition-case' around the use of
`font-lock-mark-block-function' and added some more `require' forms.

Is anybody in a position to try it out?  I want to follow the 'release
early, release often' maxim so the project regains some momentum.

I've also had a request to allow xslide to be included in a CD-ROM
that's included with a forthcoming XML book.  I'm glad that the
request has come now that xslide is progressing again, rather than a
couple of months ago when xslide was moribund.

Also, I get a new laptop tomorrow that has a 60GB disk, so I'll have
plenty of room for both Emacs and XEmacs so I can do better at
handling the Emacs/XEmacs differences w.r.t. xslide.

Regards,


Tony Graham.

Re: (xslide) GNU Emacs

[xslide S. <xsl...@me...>]

At 26 Jun 2003 23:15 -0400, xslide Support wrote:
 > One element and one attribute hash/obarray/whatever per namespace.

I'm currently expanding my consciousnes by reading 'Lisp in Small
Pieces' by Christian Queinnec.  He says hash tables are preferable to
property lists, and that's good enough for me.  Hash tables it should
be.

Regards,


Tony Graham.

Re: (xslide) Success! (please disregard previous email)

[xslide S. <xsl...@me...>]

At 11 Jun 2003 19:19 -0400, Glen Peterson wrote:
...
 > > font-lock-mark-block-function's value is 
 > > nil
 > > 
 > > Documentation:
 > > *Non-nil means use this function to mark a block of text.
 > > When called with no args it should leave point at the beginning of any
 > > enclosing textual block and mark at the end.
 > > This is normally set via `font-lock-defaults'.
 > 
 > I didn't have much luck finding an equivilant function, but mark-defun may be the closest living relative:
 > 
 > (mark-defun)
 > 
 > Documentation:
 > Put mark at end of this defun, point at beginning.
 > The defun marked is the one that contains point or follows point.
 > 
 > 
 > It looks like font-lock.el sets font-lock-mark-block-function as an alias for mark-defun in java-mode.  What do you want me to do about this?  I never missed that function, but that's just me.

I think you've got the cart before the
horse. `font-lock-mark-block-function' is what you use to tell
font-lock what function to use to work out how much to fontify.

Marking a defun makes sense for a programming language mode like
java-mode, but not for one that doesn't use parentheses.

If java-mode works for you, then presumably you do have
`font-lock-mark-block-function'.  Maybe you need to turn on font-lock
somehow, and presumably I've already got it enabled.  However, if that
really was the case, then I'd expect to get an error when I
byte-compile the .el files using the Makefile, since that disables
loading my .el file.

Regards,


Tony.

Re: (xslide) GNU Emacs

[xslide S. <xsl...@me...>]

At 24 Jun 2003 20:21 -0400, Glen Peterson wrote:
 > On Wed, 2003-06-18 at 21:56, Tony Graham wrote:
...
 > > 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. 

What we have now is an alist, which means a linear search.

 > 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 think we're talking at cross-purposes here.

Yes, get and set methods for the values associated with an individual
element or attribute.

A hash table of all of the structures/lists/vectors/arrays for the
elements (and one for the attributes) that are keyed from the element
or attribute name.

One element and one attribute hash/obarray/whatever per namespace.

The structures and hashes are built at startup from the data in
Customize (although both an XML format and the ability to save
compiled structure hashes would be useful).

One use case is to be able to successfully fontify an XSLT stylesheet
that produces another XSLT stylesheet: you have XSLT elements in two
namespaces, at least one prefix for which is not going to be 'xsl:'.
xslide, therefore, has to know to recognise this namespace aliasing,
and it has to build its font-lock-keywords on-the-fly to cope.

 > 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

Yes, it does look interesting.  `defstruct' is part of the Common Lisp
extensions, at least on Emacs 20.7, but xslide currently requires the
cl package anyway.

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

He's not the first person that I've heard of that uses xslide for HTML.

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

I want the W3C Recommendations for XSLT and XSL as Info files and to
be able to get from an element to its definition in the Info files.
There is a limit to how much people will want to put in Customize
fields, and I don't want to have to enter everything for XSLT and XSL.

...
 > > 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 want to use the semantic bovinator and associated stuff so the
font-lock stuff becomes more intelligent, as would the automatic
addition of required attributes, plus it would lead to being able to
support a 'tree view' of templates using speedbar.

You might have fun writing the lisp, but not everybody is going to be
able to write lisp to support for their tag set.

...
 > Would it be to our advantage to consider scaling the development effort
 > on this project?  Have you ever considered merging with sgml-mode?  How

My DTD mode started out as a minor mode of sgml-mode, so I have some
experience in that direction.

sgml-mode isn't going to be able to validate your average XSL file, so
a lot of its features won't apply.

I do sometimes think of PSGML's API for finding where you are in the
document, but I haven't looked closely at it.

 > 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

They contributed patches.

 > honest questions than suggestions for me right now.

Questions are welcome.

Regards,


Tony Graham.

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

Re: (xslide) GNU Emacs

[xslide S. <xsl...@me...>]

At 17 Jun 2003 23:16 -0400, Glen Peterson wrote:
 > Thank you for trying my patch!  You have made me very happy.

Right now it's more sampling than trying, since I'm not inclined to
'suck it and see' w.r.t. changing that much of xslide.

...
 > I'll quibble with you.  I find I understand the code quicker when

We can quibble in a separate message.

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

Being lazy, I tend to use `nth'.

An obarray is effectively a separate namespace for symbols.  Hence one
obarray for each XML namespace.

------------------------------------------------------------
put is a built-in function.

Store SYMBOL's PROPNAME property with value VALUE.
It can be retrieved with `(get SYMBOL PROPNAME)'.

(put SYMBOL PROPNAME VALUE)
------------------------------------------------------------

Using obarrays or just property lists, you can store named properties
attached to symbols.  I haven't done it yet because the experiments
that I tried didn't work.

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

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

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.)

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

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.

...
 > Can you reccomend a good book on ELisp or Lisp?

Programming in Emacs Lisp: An Introduction
Chassell

GNU Emacs Lisp Reference Manual (or its XEmacs equivalent)

Both of the above are available as Info files and as HTML, but you can
also buy printed and bound versions (which tend to not be as up to
date as the electronic, which is only occasionally a problem).

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

Don't sweat it.  xslide was dormant for nearly two years because I was
too busy at work, so two weeks isn't a problem.

Regards,


Tony Graham.

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

Re: (xslide) GNU Emacs

[xslide S. <xsl...@me...>]

At 12 Jun 2003 23:52 -0400, Glen Peterson wrote:
...
 > Can I do anything else to make you interested in trying my patch?  Come

Put 25 hours in a day?

 > on, guys, it's been two months.

Put that way, it is rude to not have looked at your patches.  I will
point out, however, that the patches that I have incorporated recently
were well over a year old.  But, no, you don't have to wait another
ten months.

I have started looking at your files, and I have included some of your
changes in my copies of xslide.el and xslide-font.el.

There is some good stuff there, plus some stuff that we'll need to
work on.  Naturally I like `xsl-if-to-choose', but I'll need to be
convinced why xslide needs a separate tab-stop mechanism from
tab-width.

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 was reading the Emacs Lisp manual last week (mostly because I was
surprised to find I had it in Info form on my laptop).  I was actually
reading the Emacs Lisp Coding Conventions page, so I was able to look
this part up quickly.  It says:

   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.

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.

Ignoring for the moment that `xsl-element-symbol-alist' and
`xsl-attributes-alist' are totally undocumented, there should be
enough information there to get started.

`xsl-element-symbol-alist' tells you about an element:

 - whether it is empty, block, or inline

 - its XSLT-defined attributes

 - whether or not it is required (in some cases)

`xsl-attributes-alist' tells you the list of default choices for
attribute value (if you look only at "xmlns:xsl" and are very, very
optimistic about the other attributes).

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.

So, do you (all of you) want to work with me on putting
`xsl-element-symbol-alist' (or its successor) to its intended use?

Regards,


Tony Graham.

Re: (xslide) GNU Emacs

[Colin P. A. <co...@co...>]

>>>>> "Glen" == Glen Peterson <gl...@or...> writes:

    Glen> Can I do anything else to make you interested in trying my
    Glen> patch?  Come on, guys, it's been two months.

As soon as I get round to using XSLT again ...
-- 
Colin Paul Adams
Preston Lancashire

Re: (xslide) GNU Emacs

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

I am satisfied that you can download the xslide 0.2.1 zip file and unzip
it, then unzip my latest patch (glensChanges2003-06-12.tar.gz) and it
should work right out of the box without any byte-compiling or
anything.  I should mention that if you byte compiled 0.2.1, then you
should delete xslide.elc and xslide-font.elc before using my patch, or
byte-compile my patch to overwrite those files.

I did a fresh install and patch in GNU Emacs 21.2.1 (deleted .elc) under
Red Hat Linux 8.0 and ran it through my standard smoke-test.  I've been
testing up to this point in XEmacs on Windows XP.  Let me know if you
are using any other versions.

This patch is about as stable as it's going to get.  If my patch removes
any existing functionality, (aside from emailing a bug report and
whatever that function-mark-block thing was) let me know.  You already
know you can uncomment those two lines if you have those functions
working on your system as per earlier emails on this list.

(one line)
http://sourceforge.net/tracker/?func=detail&aid=742946&group_id=22964&atid=377145

Download glensChanges2003-06-12.tar.gz

Can I do anything else to make you interested in trying my patch?  Come
on, guys, it's been two months.

-- 
---
Glen Peterson
Senior Software Engineer - Web Consultant
(978) 468-2245

(xslide) GNU Emacs

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

Tried my patch in GNU Emacs on Linux and of course, it didn't work.  GNU Emacs does not have mark-end-of-line.  It's XEmacs only.  I also added (require 'xslide) in xslide-font.  Now it compiles.

I posted a new patch without the .elc files because GNU Emacs complained about them not being GNU enough.  I'll do more testing on GNU over the weekend.  How many versions of Emacs should this be tested on?


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

Re: (xslide) Success! (please disregard previous email)

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

I posted a new version to my last patch.  All I did was merge my changes into the 0.2.1 xslide.  Well, I snuck in a few helper messages about valid attributes, values and such.

Here are my responses to Tony:

auto-autoloads.el:
Must be an XEmacs thing.  Without it, I have to load xslide manually every time I open an xsl file.

> font-lock-mark-block-function's value is 
> nil
> 
> Documentation:
> *Non-nil means use this function to mark a block of text.
> When called with no args it should leave point at the beginning of any
> enclosing textual block and mark at the end.
> This is normally set via `font-lock-defaults'.

I didn't have much luck finding an equivilant function, but mark-defun may be the closest living relative:

(mark-defun)

Documentation:
Put mark at end of this defun, point at beginning.
The defun marked is the one that contains point or follows point.


It looks like font-lock.el sets font-lock-mark-block-function as an alias for mark-defun in java-mode.  What do you want me to do about this?  I never missed that function, but that's just me.


>  > While compiling the end of the data:
>  >   ** the function mail-position-on-field is not known to be defined.
> 
> It's in sendmail.el (on Emacs).

Hmm...  sendmail.el seems ripe with compilation errors on XEmacs.  I only spent a few minutes on it though.  mail-position-on-field is in there.  What do you want me to do about this?

> Have you tried submitting a bug report using `xsl-submit-bug-report'
> with those lines commented out?

No, but I'm sure I broke it.

For now, maybe you can un-comment the two lines we discussed here and recompile on GNU emacs.  Those are the only two liberties I'm aware of taking.

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

Re: (xslide) CVS sources

[xslide S. <xsl...@me...>]

At 11 Jun 2003 08:21 -0400, Glen Peterson wrote:
 > Two things:
 > 
 > * auto-autoloads.el is missing from your CVS sources.

I don't know anything about auto-autoloads.el.

I suspect that it's an XEmacs thing, but I really don't know.

 > * Is xslide-process.el a new version of xslt-process.ell that used to be in the xslt-process directory?  How are they related (or not)?

I don't know anything about an xslt-process directory.

xslide-process.el has existed for about as long as there has been a
xslide.

 > I merged my changes with the latest sources from CVS and am testing them.

Good.

Regards,


Tony Graham.