Completion for key=value pairs

[Ralf Angeli-3]

Hi,

with `multi-prompt-key-value' we now have a function which can be used
to prompt the user for key=value pairs with completion when inserting
LaTeX macros.  listings.el uses it already, so you should be able to
test it with a LaTeX file loading listings.sty.

Listings is more or less just a showcase.  The reason I implemented
`multi-prompt-key-value' is to use it in pstricks.el instead of the
current way pstricks.el tries to prompt for macro options.  I write
"tries to" because the prompting mechanism is broken and does not work
most of the time.  Anyway, I think a completion mechanism as provided by
`multi-prompt-key-value' would be more natural and fit better into
AUCTeX than prompting for every option separately.

Please check it out with the listings example and let me know what you
think.  If there are no objections, I'll go ahead and adapt pstricks.el
to use this mechanism as well.

--
Ralf



_______________________________________________
auctex-devel mailing list
auctex-devel@...
http://lists.gnu.org/mailman/listinfo/auctex-devel

[Holger Sparr-3]

Ralf Angeli wrote:

> with `multi-prompt-key-value' we now have a function which can be used
> to prompt the user for key=value pairs with completion when inserting
> LaTeX macros.  listings.el uses it already, so you should be able to
> test it with a LaTeX file loading listings.sty.

Looks good to me.

> Listings is more or less just a showcase.  The reason I implemented
> `multi-prompt-key-value' is to use it in pstricks.el instead of the
> current way pstricks.el tries to prompt for macro options.  I write
> "tries to" because the prompting mechanism is broken and does not work
> most of the time.

I have not used myself pstricks.el for while. Just recently I noticed
that in emacs-23 a:

        (require 'cmr)

was necessary to insert to make it work again.

I thought when looking at the source again, it was way to complicated.

> Anyway, I think a completion mechanism as provided by
> `multi-prompt-key-value' would be more natural and fit better into
> AUCTeX than prompting for every option separately.

Of course.

I would suggest to insert a "=" automatically when the first completion
is uniquely done or suggest a "=" when possible.

> Please check it out with the listings example and let me know what you
> think.  If there are no objections, I'll go ahead and adapt pstricks.el
> to use this mechanism as well.

Can I be of some help?

Holger

--



_______________________________________________
auctex-devel mailing list
auctex-devel@...
http://lists.gnu.org/mailman/listinfo/auctex-devel

[Ralf Angeli-3]

* Holger Sparr (2009-03-30) writes:

> Ralf Angeli wrote:
>
>> Listings is more or less just a showcase.  The reason I implemented
>> `multi-prompt-key-value' is to use it in pstricks.el instead of the
>> current way pstricks.el tries to prompt for macro options.  I write
>> "tries to" because the prompting mechanism is broken and does not work
>> most of the time.
>
> I have not used myself pstricks.el for while. Just recently I noticed
> that in emacs-23 a:
>
>         (require 'cmr)
>
> was necessary to insert to make it work again.

I don't think this is enough.  In a freshly started Emacs and a file
using PSTricks, try to insert a pspicture environment.  In my case the
prompt of the third argument ready "Boolean" instead of "showgrid".
There seems to be a problem with the value of `parlist' in
`LaTeX-package-parameter-value'.  (In addition `compl' is let-bound but
will never be changed before its value is used.)

> I thought when looking at the source again, it was way to complicated.

This is a reason I'd like to use the new key=value completion mechanism.
However, I'm not familiar with the features the current prompting
mechanism in pstricks.el provides, since I could not try it.  Ideally
the key=value completion should at least be on par with it.

>> Anyway, I think a completion mechanism as provided by
>> `multi-prompt-key-value' would be more natural and fit better into
>> AUCTeX than prompting for every option separately.
>
> Of course.
>
> I would suggest to insert a "=" automatically when the first completion
> is uniquely done or suggest a "=" when possible.

Yeah, I know.  I experimented with "foo=" strings in the completion
table (i.e. `LaTeX-listings-key-val-options' in case of listings.el)
before committing the current version but this did not work.  I'm not
even sure yet if it is a good idea to put the "=" in the strings of the
completion table but it would be one way to distinguish keys with a
value-part from those without one (see e.g. the `print' key in the
listings package).

>> Please check it out with the listings example and let me know what you
>> think.  If there are no objections, I'll go ahead and adapt pstricks.el
>> to use this mechanism as well.
>
> Can I be of some help?

If you are interested you can replace the current prompting mechanism in
pstricks.el with the key=value completion mechanism.  As mentioned above
we should probably first determine if the key=value completion lacks
some important features the mechanism currently used has.

That reminds me: The key=value completion could possibly improved if it
provided a hint about the expected type of value if there is no fixed
set upon which a completion can be made.  For example, in the listings
package there is the key `breakindent' which accepts a dimension as
value.  In that case we could provide the user with a hint that a) it
requires a dimension and b) what a dimension actually is (e.g. "10pt").

This is just a thought.  I don't know if this would introduce too much
of an inconsistency with normal completion and how difficult this would
be to implement.

--
Ralf


_______________________________________________
auctex-devel mailing list
auctex-devel@...
http://lists.gnu.org/mailman/listinfo/auctex-devel

[Holger Sparr-3]

Ralf Angeli wrote:

> * Holger Sparr (2009-03-30) writes:
>
>> Ralf Angeli wrote:
>>
>
> I don't think this is enough.  In a freshly started Emacs and a file
> using PSTricks, try to insert a pspicture environment.  In my case the
> prompt of the third argument ready "Boolean" instead of "showgrid".
> There seems to be a problem with the value of `parlist' in
> `LaTeX-package-parameter-value'.  (In addition `compl' is let-bound but
> will never be changed before its value is used.)

You are right. I can fix this. I think I introduced 'compl' to check
whether a completion possibility was used or not. If not the the
completion list can be extended. I guess this idea was not finished.

>> I thought when looking at the source again, it was way to complicated.
>
> This is a reason I'd like to use the new key=value completion mechanism.
> However, I'm not familiar with the features the current prompting
> mechanism in pstricks.el provides, since I could not try it.  Ideally
> the key=value completion should at least be on par with it.

I think the provided history mechanism is important since the set of
used parameters will not change to much. It might be annoying to be
promptep for the same values again and again.

In case you do not use the history you will go through the completing
mechanism.

>> I would suggest to insert a "=" automatically when the first completion
>> is uniquely done or suggest a "=" when possible.
>
> Yeah, I know.  I experimented with "foo=" strings in the completion
> table (i.e. `LaTeX-listings-key-val-options' in case of listings.el)
> before committing the current version but this did not work.  I'm not
> even sure yet if it is a good idea to put the "=" in the strings of the
> completion table but it would be one way to distinguish keys with a
> value-part from those without one (see e.g. the `print' key in the
> listings package).

Will see.

> If you are interested you can replace the current prompting mechanism in
> pstricks.el with the key=value completion mechanism.  As mentioned above
> we should probably first determine if the key=value completion lacks
> some important features the mechanism currently used has.

I am interested but I can not say when I will have the time to
do some testing and experimenting.

> That reminds me: The key=value completion could possibly improved if it
> provided a hint about the expected type of value if there is no fixed
> set upon which a completion can be made.  For example, in the listings
> package there is the key `breakindent' which accepts a dimension as
> value.  In that case we could provide the user with a hint that a) it
> requires a dimension and b) what a dimension actually is (e.g. "10pt").

In the defined completion list you can add a prompt to use.


Holger

--



_______________________________________________
auctex-devel mailing list
auctex-devel@...
http://lists.gnu.org/mailman/listinfo/auctex-devel

[Ralf Angeli-3]

* Holger Sparr (2009-04-08) writes:

> Ralf Angeli wrote:
>>
>> This is a reason I'd like to use the new key=value completion mechanism.
>> However, I'm not familiar with the features the current prompting
>> mechanism in pstricks.el provides, since I could not try it.  Ideally
>> the key=value completion should at least be on par with it.
>
> I think the provided history mechanism is important since the set of
> used parameters will not change to much. It might be annoying to be
> promptep for the same values again and again.
>
> In case you do not use the history you will go through the completing
> mechanism.

There is a history for the full key=value arguments and we'd still keep
the separate histories defined in pstricks.el as long as they are used
for separate macro arguments (points, angles, arrows, etc.)  which is
the case for most uses, as far as I can see.

The key=value completion would mostly be used for what now is covered by
`LaTeX-pst-parameters'.  I've switched that to key=value completion in
my local copy of pstricks.el.  You can check it out with the attached
patch which obviously is still kinda rough.  It also contains some
comments we should address.

The patch applies to the latest version CVS where I made a few basic
changes not influencing the handling.  Mostly bug fixes and changes of
prompts to bring them in line with coding conventions.

--
Ralf

---

--- pstricks.el.~1.5.~ 2009-04-13 18:34:30.000000000 +0200
+++ pstricks.el 2009-04-13 19:33:05.000000000 +0200
@@ -69,6 +69,8 @@
                        (funcall func prompt list nil compl nil hist)))))
       (completing-read (concat prompt ": ") list nil nil nil hist))))
 
+;; XXX: Show default value in prompt.  Perhaps extend
+;; `TeX-argument-prompt' to do that.
 (defun LaTeX-pst-what (what prompt default &optional arg)
   "Ask for WHAT with PROMPT with DEFAULT.
 The corresponding lists LaTeX-pst-<what>-\\(list\\|history\\)
@@ -123,6 +125,9 @@
                (concat "(Press TAB for completions) " param)
                (intern (concat "LaTeX-" pname
                                "-parameters-value-history"))))
+    ;; FIXME: This looks broken.  `compl' is never set and unless ""
+    ;; is added to parlist (at least in the Boolean case), the prompt
+    ;; shown by `TeX-arg-compl-list' will be incorrect.
     (if (and (not compl) parlist) (add-to-list parlist val))
     (if (string= val "") "" (concat param "=" val))))
 
@@ -257,6 +262,8 @@
 (defvar LaTeX-pst-arrows-history nil
   "History of values for arrows in pstricks.")
 
+;; XXX: Better ask for arrow start and end separately?
+;; `LaTeX-pst-arrows-list' is not exhaustive.
 (defun LaTeX-pst-arrows ()
   "Ask for a arrow type and manage arrow type list"
   (or (LaTeX-pst-what "arrows" "Arrow type" nil) ""))
@@ -286,16 +293,16 @@
   (LaTeX-pst-what "refpoint" "Reference point" nil))
 
 ;;; Color
-(defvar LaTeX-pst-color-list
-  '((completing-read-multiple
-     "Color (C1 [number [C1 [...]]])" t LaTeX-pst-color-history "!")
-    "black" "darkgray" "gray" "lightgray" "white" "-black" "-darkgray"
-    "-gray" "-lightgray" "-white" "red" "green" "blue" "yellow"
-    "magenta" "cyan" "-red" "-green" "-blue" "-yellow" "-magenta"
-    "-cyan" "violet" "purple" "brown" "pink" "olive" "-violet" "-purple"
-    "-brown" "-pink" "-olive"
-    "10" "20" "30" "40" "50" "60" "70" "80" "90")
-  "A list of values for *color in pstricks.")
+;; (defvar LaTeX-pst-color-list
+;;   '((completing-read-multiple
+;;      "Color (C1 [number [C1 [...]]])" t LaTeX-pst-color-history "!")
+;;     "black" "darkgray" "gray" "lightgray" "white" "-black" "-darkgray"
+;;     "-gray" "-lightgray" "-white" "red" "green" "blue" "yellow"
+;;     "magenta" "cyan" "-red" "-green" "-blue" "-yellow" "-magenta"
+;;     "-cyan" "violet" "purple" "brown" "pink" "olive" "-violet" "-purple"
+;;     "-brown" "-pink" "-olive"
+;;     "10" "20" "30" "40" "50" "60" "70" "80" "90")
+;;   "A list of values for *color in pstricks.")
 
 (defvar LaTeX-pst-color-history nil
   "History of values for color in pstricks.")
@@ -346,6 +353,146 @@
     "trimode" "unit" "xunit" "yunit")
   "A list of parameter names in pstricks.")
 
+(defvar LaTeX-pst-color-list
+  '("black" "darkgray" "gray" "lightgray" "white"
+    "red" "green" "blue" "cyan" "magenta" "yellow")
+  "List of colors predefined in PSTricks.")
+
+(defvar LaTeX-pst-fillstyle-list
+  '("none" "solid" "vlines" "vlines*" "hlines" "hlines*" "crosshatch"
+    "crosshatch*" "boxfill")
+  "List of fill styles defined in PSTricks.")
+
+;; From PSTricks: PostScript macros for Generic TeX, User's Guide,
+;; Timothy Van Zandt, 25 July 2003, Version 97.
+;; FIXME: Provide separate variables tailored to the different macros.
+(defvar LaTeX-pst-basic-parameters-list
+  '(;; Dimensions, coordinates and angles
+    ("unit")
+    ("xunit")
+    ("yunit")
+    ("runit")
+    ;; Basic graphics parameters
+    ("linewidth")
+    ("linecolor" LaTeX-pst-color-list)
+    ("fillstyle" LaTeX-pst-fillstyle-list)
+    ("fillcolor" LaTeX-pst-color-list)
+    ("arrows" LaTeX-pst-arrows-list)
+    ("showpoints" ("true" "false"))
+    ;; Lines and polygons
+    ("linearc")
+    ("framearc")
+    ("cornersize" ("relative" "absolute"))
+    ("gangle")
+    ;; Arcs, circles and ellipses
+    ("arcsepA")
+    ("arcsepB")
+    ("arcsep")
+    ;; Curves
+    ("curvature")
+    ;; Dots
+    ("dotstyle" ("*" "o" "Bo" "x" "+" "B+" "asterisk" "Basterisk" "oplus"
+ "otimes" "|" "B|" "square" "Bsquare" "square*" "diamond"
+ "Bdiamond" "diamond*" "triangle" "Btriangle" "triangle*"
+ "pentagon" "Bpentagon" "pentagon*"))
+    ("dotsize")
+    ("dotscale")
+    ("dotangle")
+    ;; Grids
+    ("gridwidth")
+    ("gridcolor" LaTeX-pst-color-list)
+    ("griddots")
+    ("gridlabels")
+    ("gridlabelcolor" LaTeX-pst-color-list)
+    ("subgriddiv")
+    ("subgridwidth")
+    ("subgridcolor" LaTeX-pst-color-list)
+    ("subgriddots")
+    ;; Plots
+    ("plotstyle" ("dots" "line" "polygon" "curve" "ecurve" "ccurve"))
+    ("plotpoints")
+    ;; Coordinate systems
+    ("origin")
+    ("swapaxes" ("true" "false"))
+    ;; Line styles
+    ("dash")
+    ("dotsep")
+    ("border")
+    ("bordercolor" LaTeX-pst-color-list)
+    ("doubleline" ("true" "false"))
+    ("doublesep")
+    ("doublecolor" LaTeX-pst-color-list)
+    ("shadow" ("true" "false"))
+    ("shadowsize")
+    ("shadowangle")
+    ("shadowcolor" LaTeX-pst-color-list)
+    ("dimen" ("outer" "inner" "middle"))
+    ;; Fill styles
+    ("hatchwidth")
+    ("hatchsep")
+    ("hatchcolor" LaTeX-pst-color-list)
+    ("hatchangle")
+    ("addfillstyle" LaTeX-pst-fillstyle-list)
+    ;; Arrowheads and such
+    ("arrowsize")
+    ("arrowlength")
+    ("arrowwinset")
+    ("tbarsize")
+    ("bracketlength")
+    ("rbracketlength")
+    ("arrowscale")
+    ;; Parameters
+    ("linetype")
+    ;; Graphics objects
+    ("liftpen")
+    ;; Placing and rotating whatever
+    ("labelsep")
+    ;; Axes
+    ("labels" ("all" "x" "y" "none"))
+    ("showorigin" ("true" "false"))
+    ("ticks" ("all" "x" "y" "none"))
+    ("tickstyle" ("full" "top" "bottom"))
+    ("ticksize")
+    ("axesstyle" ("axes" "frame" "none"))
+    ;; Framed boxes
+    ("framesep")
+    ("boxsep")
+    ("trimode" ("*" "U" "D" "R" "L"))
+    ;; Nodes
+    ("href")
+    ("vref")
+    ("radius")
+    ;; Node connections
+    ("nodesep")
+    ("arcangle")
+    ("angle")
+    ("arm")
+    ("loopsize")
+    ("ncurv")
+    ("boxsize")
+    ("offset")
+    ;; Node connections labels: I
+    ("ref")
+    ("nrot")
+    ("npos")
+    ("shortput" ("none" "nab" "tablr" "tab"))
+    ;; Node connection labels: II
+    ("tpos")
+    ;; Attaching labels to nodes
+    ("rot")
+    ;; Mathematical diagrams and graphs
+    ("mnode" ("R" "r" "C" "f" "p" "circle" "oval" "dia" "tri" "dot" "none"))
+    ("emnode" ("R" "r" "C" "f" "p" "circle" "oval" "dia" "tri" "dot" "none"))
+    ("name")
+    ("nodealign" ("true" "false"))
+    ("mcol" ("l" "r" "c"))
+    ("rowsep")
+    ("colsep")
+    ("mnodesize")
+    ;; ...
+    )
+  "List of keys and values for PSTricks macro arguments.")
+
 (defvar LaTeX-pst-parameters-name-list
   LaTeX-pst-basic-parameters-name-list
   "A list of all parameters with completion.")
@@ -369,9 +516,16 @@
   "See documentation of `LaTeX-package-parameters-pref-and-chosen'."
   (LaTeX-package-parameters-pref-and-chosen param "pst" noskip))
 
-(defun LaTeX-pst-parameters (optional &optional preparam param)
-  "See documentation of `LaTeX-package-parameters-pref-and-chosen'."
-  (LaTeX-package-parameters optional "pst" preparam param))
+;; (defun LaTeX-pst-parameters (optional &optional preparam param)
+;;   "See documentation of `LaTeX-package-parameters-pref-and-chosen'."
+;;   (LaTeX-package-parameters optional "pst" preparam param))
+
+;; FIXME: This is likely only a transitional function used until all
+;; macros got their calls to `TeX-arg-key-val' with tailored parameter
+;; lists.
+(defun LaTeX-pst-parameters (optional)
+  "Prompt for general parameters of a PSTricks argument."
+  (TeX-arg-key-val optional LaTeX-pst-basic-parameters-list))
 
 ;;; Macros
 (defun LaTeX-pst-macro-psarc (optional &optional arg)
@@ -430,8 +584,6 @@
 
 (defun LaTeX-pst-macro-psdots (optional single)
   "Return \\psdot[s]? arguments after querying."
-  ;; forced parameter dotstyle
-  (LaTeX-pst-parameters optional '("dotstyle"))
   (let* ((pnt1 (LaTeX-pst-point))
          (pnt2 (if single pnt1 (LaTeX-pst-point))))
     (insert "(" pnt1 ")")
@@ -496,17 +648,21 @@
 (defun LaTeX-pst-macro-newpsobject (&optional arg)
   "Return \\newpsobject arguments after querying."
   (insert "{" (read-string "New PSObject Name: ") "}"
+  ;; FIXME: It would be better to use something more confined
+  ;; than `TeX-symbol-list'.
           "{" (completing-read "Parent Object: " (TeX-symbol-list))
           "}"))
 
 ;;; Environments
 (defun LaTeX-pst-env-pspicture (env)
   "Create new pspicure environment."
-  (let ((p0 (LaTeX-pst-what "point" "Lower left (default 0,0)" "0,0"))
+  (let ((opt (multi-prompt-key-value
+      (TeX-argument-prompt t "Options" nil)
+      '(("showgrid") ("shift"))))
+ (p0 (LaTeX-pst-what "point" "Lower left (default 0,0)" "0,0"))
         (p1 (LaTeX-pst-what "point" "Upper right (default 1,1)" "1,1"))
-        (grid (LaTeX-pst-parameters-pref-and-chosen '("showgrid")))
         corn)
-    (setq corn (concat (if (string= "" grid) "" (format "[%s]" grid))
+    (setq corn (concat (unless (string= "" opt) (format "[%s]" opt))
                        (if (string= "0,0" p0) "" (format "(%s)" p0))
                        "(" p1 ")"))
     (LaTeX-insert-environment env corn)))
@@ -545,6 +701,7 @@
               (add-to-list 'LaTeX-pst-style-list (nth 1 list) t))
              ((string= type "color")
               (add-to-list 'LaTeX-pst-color-list (nth 1 list) t)
+      ;; FIXME: Why is an entry with "-" in front added?
               (add-to-list 'LaTeX-pst-color-list
                            (concat "-" (nth 1 list)) t)))))
    LaTeX-auto-pstricks))
@@ -553,6 +710,8 @@
   "Clear `LaTeX-auto-pstricks' before use."
   (setq LaTeX-auto-pstricks nil))
 
+;; FIXME: This does not seem to work unless one does a manual reparse.
+;; Check e.g. with "\definecolor" and "fillcolor=".
 (add-hook 'TeX-auto-prepare-hook 'LaTeX-pst-prepare)
 (add-hook 'TeX-auto-cleanup-hook 'LaTeX-pst-cleanup)
 
@@ -617,6 +776,10 @@
                             "-list")))))
     (insert (TeX-arg-compl-list (symbol-value symb) "New Value"
                                 'LaTeX-pst-parameters-value-history))))
+;; FIXME: Does the key binding fit into the overall scheme of AUCTeX?
+;; (Changing existing content is often done with a C-u prefix to an
+;; insertion command.)  If we keep it, it should be documented in the
+;; manual.  (See also `LaTeX-pst-parameters-add'.)
 (define-key LaTeX-mode-map "\C-c\C-x\C-v" 'LaTeX-pst-parameter-change-value)
 
 (TeX-add-style-hook
@@ -669,8 +832,8 @@
       (LaTeX-pst-macro-pnt-twolen "Width" "Height"))
     '("pstriangle" [LaTeX-pst-parameters]
       (LaTeX-pst-macro-pnt-twolen "Width" "Height"))
-    '("psdot" [LaTeX-pst-macro-psdots t])
-    '("psdots" [LaTeX-pst-macro-psdots nil])
+    '("psdot" [LaTeX-pst-parameters] (LaTeX-pst-macro-psdots t))
+    '("psdots" [LaTeX-pst-parameters] (LaTeX-pst-macro-psdots nil))
     '("psecurve" [LaTeX-pst-parameters] LaTeX-pst-macro-psline)
     '("psecurve*" [LaTeX-pst-parameters] LaTeX-pst-macro-psline)
     '("psellipse" [LaTeX-pst-parameters]

---

_______________________________________________
auctex-devel mailing list
auctex-devel@...
http://lists.gnu.org/mailman/listinfo/auctex-devel

[Ralf Angeli-3]

* Ralf Angeli (2009-04-13) writes:

> The key=value completion would mostly be used for what now is covered by
> `LaTeX-pst-parameters'.  I've switched that to key=value completion in
> my local copy of pstricks.el.  You can check it out with the attached
> patch which obviously is still kinda rough.  It also contains some
> comments we should address.

Since I haven't heard from Holger for about half a year now, I applied
the patch in CVS.  As mentioned before it's a bit rough and there are
many areas for improvement (see the FIXME notes) but overall the
handling of parameter insertion and completion should be better than
before.

Note that I disabled the key bindings for the macro parameter addition
and change functions because the functions are too specific to
pstricks.el to warrant such a binding.  If people are opposed to the
removal, we could provide a variable for enabling the binding in order
to make that easier for users.  But ideally that should be a general
functionality and not one of pstricks.el.  In that case I would not have
a problem with providing a fixed binding.

Anyway, comments and patches are welcome to improve pstricks.el further.

--
Ralf


_______________________________________________
auctex-devel mailing list
auctex-devel@...
http://lists.gnu.org/mailman/listinfo/auctex-devel