non-space, paste, (???) character for inline results

non-space, paste, (???) character for inline results

[Greg Minshall]

hi.  thanks again for org-mode.

having discovered this variable, i tend to run with
: #+bind: org-babel-inline-result-wrap "%s"

but, at the same time, i'd often like to put some character(s) before or
after the result of some particular inline call, e.g., a dollar sign, a
percent, etc.

i could, i suppose, rebind o-b-i-r-wrap around those calls, but...

if one writes, e.g., $call_foo(), the call_foo() doesn't happen
(presumably isn't recognized).

i've tried various constructs that might allow the evaluation to be
recognize the call, but "paste" the result in with no intervening space,
things like
: #+macro: null
: ${{{null}}}call_foo()
but to no avail.  (in the above case, i'm assuming macro expansion
happens *before* inline calls -- as it should -- so the inline call
procedure sees, e.g., $call_foo() and, again, doesn't distinguish it.)

does such a construct exist?  if not, would it make sense (and be
possible, given the installed base!) to add some such?  (if so, i'd
probably vote for {{{}}}, the "null" macro which, anyway, currently
isn't modified -- in my setup, anyway -- during export.)

cheers, Greg

Re: non-space, paste, (???) character for inline results

[Nicolas Goaziou]

Hello,

Greg Minshall <minshall@acm.org> writes:

> hi.  thanks again for org-mode.
>
> having discovered this variable, i tend to run with
> : #+bind: org-babel-inline-result-wrap "%s"
>
> but, at the same time, i'd often like to put some character(s) before or
> after the result of some particular inline call, e.g., a dollar sign, a
> percent, etc.
>
> i could, i suppose, rebind o-b-i-r-wrap around those calls, but...
>
> if one writes, e.g., $call_foo(), the call_foo() doesn't happen
> (presumably isn't recognized).
>
> i've tried various constructs that might allow the evaluation to be
> recognize the call, but "paste" the result in with no intervening space,
> things like
> : #+macro: null
> : ${{{null}}}call_foo()
> but to no avail.  (in the above case, i'm assuming macro expansion
> happens *before* inline calls -- as it should -- so the inline call
> procedure sees, e.g., $call_foo() and, again, doesn't distinguish it.)
>
> does such a construct exist?  if not, would it make sense (and be
> possible, given the installed base!) to add some such?  (if so, i'd
> probably vote for {{{}}}, the "null" macro which, anyway, currently
> isn't modified -- in my setup, anyway -- during export.)

This is now fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: non-space, paste, (???) character for inline results

[Greg Minshall]

Nicolas,

great!  except, oh, well, maybe you really meant to respond to this
other set of messages, with subject line
----
Re: [O] BUG report [Was: computing the size of a tikz to png image during export]
---

cheers, Greg

Re: non-space, paste, (???) character for inline results

[Nicolas Goaziou]

Hello,

Greg Minshall <minshall@acm.org> writes:

> great!  except, oh, well, maybe you really meant to respond to this
> other set of messages, with subject line
> ----
> Re: [O] BUG report [Was: computing the size of a tikz to png image during export]
> ---

Both are fixed, actually, so it doesn't matter the way you look at it :)

Regards,

-- 
Nicolas Goaziou                                                0x80A93738

Re: non-space, paste, (???) character for inline results

[Greg Minshall]

Nico,

ah, thanks!

not wanting to look gift horses, etc., but i've a question.  if i
understand the change correctly
----
-             (looking-at "\\<call_\\([^ \t\n[(]+\\)[([]"))
+             (looking-at "call_\\([^ \t\n[(]+\\)[([]"))
----
now something like "oncall_foo()" will be taken as "on" followed by the
inline results of call_foo().  is that right?  (testing, seems to be.)

i worry that might be a bit too lenient.  sometimes one might want
"oncall_foo()" to stay as "oncall_foo()".  (that's why i was thinking of
some, hmm, "non-spacing break", like the string "{{{}}}", or, well,
almost anything, "\.", "\#", "#" -- maybe the cleanest? -- ...)

cheers, Greg

Re: non-space, paste, (???) character for inline results

[Nicolas Goaziou]

Hello,

Greg Minshall <minshall@acm.org> writes:

> not wanting to look gift horses, etc., but i've a question.  if i
> understand the change correctly
> ----
> -             (looking-at "\\<call_\\([^ \t\n[(]+\\)[([]"))
> +             (looking-at "call_\\([^ \t\n[(]+\\)[([]"))
> ----
> now something like "oncall_foo()" will be taken as "on" followed by the
> inline results of call_foo().  is that right?  (testing, seems to be.)

Correct.

> i worry that might be a bit too lenient.

Note there is no such restriction on macros either, so you can write

  on{{{call}}}

If "call" macro expands to "call_foo()", you get a surprising error if
the inline call is not expanded thereafter.

> sometimes one might want "oncall_foo()" to stay as "oncall_foo()".

In this case, you can use verbatim markup, or even non-breaking space
before the underscore.

Whatever the regexp we use, some contexts will require non-breaking
space anyway. The current solution is at least consistent with other
parts of Org (e.g., macros).

WDYT?

Regards,

-- 
Nicolas Goaziou

Re: non-space, paste, (???) character for inline results

[Greg Minshall]

[-- Attachment #1: Type: text/plain, Size: 905 bytes --]

Nico,

thanks.  neither =verbatim markup= (if that's the usage), nor a
non~breaking~space give me, in my output, a plain, unadorned
"xxcall_foo()".

i *do* think xxcall_foo() is very intuitive for both sets of people,
both those who want xx+results and those who want literal xxcall_foo().

so, probably there's no right, wrong.  but, imho, there should be some
fairly simple way to export, in the text one wants, a simple literal
xxcall_foo() (as well as a simple way to export xx+results).

all said and done, probably (aesthetics?) i'd go for using a hash (#) as
the "paste" character.  i guess it's a bit more complicated than just
changing:
----
: (looking-at "\\<[#]?call_\\([^ \t\n[(]+\\)[([]"))
----
in ob-element.el.  below is my cut.  (i used two invocations of
"string-prefix-p" rather than one "string-match", not being sure how
expensive the latter is compared to the former.)

cheers, Greg


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-use-as-a-paste-character-for-call_-and-src_.patch --]
[-- Type: text/x-diff, Size: 1761 bytes --]

From e0337aabb13fabcefbb0a9fd65e8d4c9bcd412ee Mon Sep 17 00:00:00 2001
From: Greg Minshall <minshall@acm.org>
Date: Wed, 31 Jan 2018 20:38:35 +0530
Subject: [PATCH] use '#' as a "paste" character (for call_ and src_)

---
 lisp/org-element.el | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index 5af2d6e..5fc3b2d 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -162,7 +162,7 @@ specially in `org-element--object-lex'.")
 		      "\\\\\\(?:[a-zA-Z[(]\\|\\\\[ \t]*$\\|_ +\\)"
 		      ;; Objects starting with raw text: inline Babel
 		      ;; source block, inline Babel call.
-		      "\\(?:call\\|src\\)_"))
+		      "#?\\(?:call\\|src\\)_"))
 		   "\\|")))
 
 (org-element--set-regexps)
@@ -2878,7 +2878,7 @@ Assume point is at the beginning of the babel call."
   (save-excursion
     (catch :no-object
       (when (let ((case-fold-search nil))
-	      (looking-at "call_\\([^ \t\n[(]+\\)[([]"))
+	      (looking-at "#?\\<call_\\([^ \t\n[(]+\\)[([]"))
 	(goto-char (match-end 1))
 	(let* ((begin (match-beginning 0))
 	       (call (match-string-no-properties 1))
@@ -4383,10 +4383,12 @@ to an appropriate container (e.g., a paragraph)."
 	  (let ((result (match-string 0)))
 	    (setq found
 		  (cond
-		   ((string-prefix-p "call_" result t)
+		   ((or (string-prefix-p "call_" result t)
+			(string-prefix-p "#call_" result t))
 		    (and (memq 'inline-babel-call restriction)
 			 (org-element-inline-babel-call-parser)))
-		   ((string-prefix-p "src_" result t)
+		   ((or (string-prefix-p "src_" result t)
+			(string-prefix-p "#src_" result t))
 		    (and (memq 'inline-src-block restriction)
 			 (org-element-inline-src-block-parser)))
 		   (t
-- 
2.7.4

Re: non-space, paste, (???) character for inline results

[Nicolas Goaziou]

Greg Minshall <minshall@acm.org> writes:

> thanks.  neither =verbatim markup= (if that's the usage), nor a
> non~breaking~space give me, in my output, a plain, unadorned
> "xxcall_foo()".

I meant zero-width space, not non-breaking space. Note that it can be
used in other places to escape special characters, e.g., verbatim
markup.

Re: non-space, paste, (???) character for inline results

[Greg Minshall]

[-- Attachment #1: Type: text/plain, Size: 556 bytes --]

Nico,

> I meant zero-width space, not non-breaking space. Note that it can be
> used in other places to escape special characters, e.g., verbatim
> markup.

ah.  how does one enter a zero-width space in emacs/org-mode?  also, i'm
curious about how it looks on the screen.  (for me, i'd want it to look,
on the screen, *very* obvious that *something* is there.)

i also apologize that the patch i sent before is incomplete -- i forgot
to modify a bit of "src_" processing; a new attempt is below.  (not sure
if that format is suitable.)

cheers, Greg
----

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-use-as-a-paste-character-for-call_-and-src_-2.patch --]
[-- Type: text/x-diff, Size: 2585 bytes --]

From e0337aabb13fabcefbb0a9fd65e8d4c9bcd412ee Mon Sep 17 00:00:00 2001
From: Greg Minshall <minshall@acm.org>
Date: Wed, 31 Jan 2018 20:38:35 +0530
Subject: [PATCH 1/2] use '#' as a "paste" character (for call_ and src_)

---
 lisp/org-element.el | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index 5af2d6e..5fc3b2d 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -162,7 +162,7 @@ specially in `org-element--object-lex'.")
 		      "\\\\\\(?:[a-zA-Z[(]\\|\\\\[ \t]*$\\|_ +\\)"
 		      ;; Objects starting with raw text: inline Babel
 		      ;; source block, inline Babel call.
-		      "\\(?:call\\|src\\)_"))
+		      "#?\\(?:call\\|src\\)_"))
 		   "\\|")))
 
 (org-element--set-regexps)
@@ -2878,7 +2878,7 @@ Assume point is at the beginning of the babel call."
   (save-excursion
     (catch :no-object
       (when (let ((case-fold-search nil))
-	      (looking-at "call_\\([^ \t\n[(]+\\)[([]"))
+	      (looking-at "#?\\<call_\\([^ \t\n[(]+\\)[([]"))
 	(goto-char (match-end 1))
 	(let* ((begin (match-beginning 0))
 	       (call (match-string-no-properties 1))
@@ -4383,10 +4383,12 @@ to an appropriate container (e.g., a paragraph)."
 	  (let ((result (match-string 0)))
 	    (setq found
 		  (cond
-		   ((string-prefix-p "call_" result t)
+		   ((or (string-prefix-p "call_" result t)
+			(string-prefix-p "#call_" result t))
 		    (and (memq 'inline-babel-call restriction)
 			 (org-element-inline-babel-call-parser)))
-		   ((string-prefix-p "src_" result t)
+		   ((or (string-prefix-p "src_" result t)
+			(string-prefix-p "#src_" result t))
 		    (and (memq 'inline-src-block restriction)
 			 (org-element-inline-src-block-parser)))
 		   (t
-- 
2.7.4


From b032d0860431ff29e7136145605d4f3d981d5301 Mon Sep 17 00:00:00 2001
From: Greg Minshall <minshall@acm.org>
Date: Wed, 31 Jan 2018 22:53:06 +0530
Subject: [PATCH 2/2] oops, forgot (looking-at .*src_...)

---
 lisp/org-element.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index 5fc3b2d..7f70f4a 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -2932,7 +2932,7 @@ Assume point is at the beginning of the inline src block."
   (save-excursion
     (catch :no-object
       (when (let ((case-fold-search nil))
-	      (looking-at "src_\\([^ \t\n[{]+\\)[{[]"))
+	      (looking-at "#?\\<src_\\([^ \t\n[{]+\\)[{[]"))
 	(goto-char (match-end 1))
 	(let ((begin (match-beginning 0))
 	      (language (match-string-no-properties 1))
-- 
2.7.4

Re: non-space, paste, (???) character for inline results

[Kaushal Modi]

[-- Attachment #1.1: Type: text/plain, Size: 2066 bytes --]

On Wed, Jan 31, 2018 at 12:44 PM Greg Minshall <minshall@acm.org> wrote:

>
> ah.  how does one enter a zero-width space in emacs/org-mode?


By default, you can do C-x 8 RET and type ZERO WIDTH SPACE and the 0x200b
character will be inserted.

I use it once in a while, so I have bound it to C-x 8 0 [1].


>   also, i'm
> curious about how it looks on the screen.  (for me, i'd want it to look,
> on the screen, *very* obvious that *something* is there.)
>

I have been bit by ZERO WIDTH SPACE characters present in Org buffer and
getting wrong fontification.. and so I came up with [2]:

(defun modi/highlight-confusing-chars ()
  "Highlight confusing characters in different glyphs + face.

EN DASH          -> 2 Hyphens
EM DASH          -> 3 Hyphens
ZERO WIDTH SPACE -> ∅

All glyphs are shown in `modi/highlight-confusing' face."
  (let* ((glyph-en-dash (make-glyph-code ?- 'modi/highlight-confusing))
;HYPHEN-MINUS follows that ?
         (glyph-em-dash glyph-en-dash)  ;HYPHEN-MINUS follows that ?
         (glyph-zws (make-glyph-code ?∅ 'modi/highlight-confusing)))
    (when (not buffer-display-table)
      (setq buffer-display-table (make-display-table)))
    (aset buffer-display-table ?– `[,glyph-en-dash ,glyph-en-dash]) ;EN
DASH follows that ?
    (aset buffer-display-table ?— `[,glyph-em-dash ,glyph-em-dash
,glyph-em-dash]) ;EM DASH follows that ?
    (aset buffer-display-table ?​ `[,glyph-zws])))
(dolist (hook '(prog-mode-hook
                org-mode-hook))
  (add-hook hook #'modi/highlight-confusing-chars))

It's not evident in the above code, but there' actually a ZERO WIDTH SPACE
char after the ? in the third aset form.. and it looks like this (image
pasted below) to me :)

[image: image.png]



[1]:
https://github.com/kaushalmodi/.emacs.d/blob/d8877836b8566a8831c735a8ec2000133230ad41/setup-files/setup-unicode.el#L40
[2]:
https://github.com/kaushalmodi/.emacs.d/blob/d8877836b8566a8831c735a8ec2000133230ad41/setup-files/setup-visual.el#L617-L635
-- 

Kaushal Modi

[-- Attachment #1.2: Type: text/html, Size: 3146 bytes --]

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 69053 bytes --]

Re: non-space, paste, (???) character for inline results

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 438 bytes --]

On Wed, Jan 31, 2018 at 12:51 PM Kaushal Modi <kaushal.modi@gmail.com>
wrote:

>
> All glyphs are shown in `modi/highlight-confusing' face."
>

Forgot to paste the face definition (I just set it to colors to suit my
default theme):

(defface modi/highlight-confusing
  '((t (:foreground "black"
        :background "#b0b0b0")))
  "Face used to highlight confusing characters.
Used in `modi/highlight-confusing-chars'.")
-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 945 bytes --]

Re: non-space, paste, (???) character for inline results

[Nicolas Goaziou]

Greg Minshall <minshall@acm.org> writes:

> ah.  how does one enter a zero-width space in emacs/org-mode?  also, i'm
> curious about how it looks on the screen.  (for me, i'd want it to look,
> on the screen, *very* obvious that *something* is there.)
>
> i also apologize that the patch i sent before is incomplete -- i forgot
> to modify a bit of "src_" processing; a new attempt is below.  (not sure
> if that format is suitable.)

At some point, someone will want to write foo#call_bar() without
#call_bar() being replaced, and we will go back to point 0. IMO,
zero-width space is the way to go, if only because it can already be
used to escape other special characters in Org.

Re: non-space, paste, (???) character for inline results

[Greg Minshall]

[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]

Nico,

> At some point, someone will want to write foo#call_bar() without
> #call_bar() being replaced, and we will go back to point 0. IMO,
> zero-width space is the way to go, if only because it can already be
> used to escape other special characters in Org.

oof, of course!  color me convinced!

one concern: if i essentially "revert" the changes in
7efa0f2879226695ad9b309c9263a4d1b5d79e89, call_ and src_ all work, but i
get the ZERO WIDTH SPACE (ZSWP, \u200b) propagated into the resulting
output file (.html, .tex). it doesn't seem to do any "harm", but, i find
it disquieting (being an ASCII-type by birth, if not by current usage).

the below patch, basically my #-paste patch turned into a \u200b-paste
patch, gets rid of the ZWSP in the output file in the case of
\u200bcall_, \u200bsrc_ (**), but, leaves it for all other uses, i.e.,
\u200b=fubar=.  this inconsistency i *also* find disquieting, sigh; i
can imagine the great-regexp in the sky in org-element.el could get rid
of all these prefixing ZWSPs, but i'd not proceed in this direction
without (policy, at least) direction.

cheers, Greg

(**) btw, if one wants \u200b<<RESULTS OF CALL_FOO()>> in the output,
one prefixes CALL_FOO() with *two* ZWSPs.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-use-ZERO-WIDTH-SPACE-as-a-separator-for-call_-src_.patch --]
[-- Type: text/x-diff, Size: 2947 bytes --]

From df94d943d085947212d96eddec9870d7dca0ea23 Mon Sep 17 00:00:00 2001
From: Greg Minshall <minshall@acm.org>
Date: Thu, 1 Feb 2018 11:32:59 +0530
Subject: [PATCH] use ZERO WIDTH SPACE as a separator for call_, src_

(but, don't leave around in output)
---
 lisp/org-element.el         | 15 +++++++++------
 testing/lisp/test-ob-exp.el |  2 +-
 2 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index 5af2d6e..f550b89 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -161,8 +161,9 @@ specially in `org-element--object-lex'.")
 		      ;; entity, latex fragment.
 		      "\\\\\\(?:[a-zA-Z[(]\\|\\\\[ \t]*$\\|_ +\\)"
 		      ;; Objects starting with raw text: inline Babel
-		      ;; source block, inline Babel call.
-		      "\\(?:call\\|src\\)_"))
+		      ;; source block, inline Babel call.  possibly
+		      ;; prefixed with ZERO WIDTH SPACE
+		      "\u200b?\\(?:call\\|src\\)_"))
 		   "\\|")))
 
 (org-element--set-regexps)
@@ -2878,7 +2879,7 @@ Assume point is at the beginning of the babel call."
   (save-excursion
     (catch :no-object
       (when (let ((case-fold-search nil))
-	      (looking-at "call_\\([^ \t\n[(]+\\)[([]"))
+	      (looking-at "\u200b?\\<call_\\([^ \t\n[(]+\\)[([]"))
 	(goto-char (match-end 1))
 	(let* ((begin (match-beginning 0))
 	       (call (match-string-no-properties 1))
@@ -2932,7 +2933,7 @@ Assume point is at the beginning of the inline src block."
   (save-excursion
     (catch :no-object
       (when (let ((case-fold-search nil))
-	      (looking-at "src_\\([^ \t\n[{]+\\)[{[]"))
+	      (looking-at "\u200b?\\<src_\\([^ \t\n[{]+\\)[{[]"))
 	(goto-char (match-end 1))
 	(let ((begin (match-beginning 0))
 	      (language (match-string-no-properties 1))
@@ -4383,10 +4384,12 @@ to an appropriate container (e.g., a paragraph)."
 	  (let ((result (match-string 0)))
 	    (setq found
 		  (cond
-		   ((string-prefix-p "call_" result t)
+		   ((or (string-prefix-p "call_" result t)
+			(string-prefix-p "\u200bcall_" result t))
 		    (and (memq 'inline-babel-call restriction)
 			 (org-element-inline-babel-call-parser)))
-		   ((string-prefix-p "src_" result t)
+		   ((or (string-prefix-p "src_" result t)
+			(string-prefix-p "\u200bsrc_" result t))
 		    (and (memq 'inline-src-block restriction)
 			 (org-element-inline-src-block-parser)))
 		   (t
diff --git a/testing/lisp/test-ob-exp.el b/testing/lisp/test-ob-exp.el
index b0a3ab2..d8e1df1 100644
--- a/testing/lisp/test-ob-exp.el
+++ b/testing/lisp/test-ob-exp.el
@@ -231,7 +231,7 @@ Here is one at the end of a line. {{{results(=2=)}}}
   (should
    (equal "foosrc_emacs-lisp[]{(+ 1 1)}"
 	  (org-test-with-temp-text
-	      "foosrc_emacs-lisp[:exports code]{(+ 1 1)}"
+	      "foo\u200bsrc_emacs-lisp[:exports code]{(+ 1 1)}"
 	    (let ((org-babel-inline-result-wrap "=%s=")
 		  (org-export-use-babel t))
 	      (org-babel-exp-process-buffer))
-- 
2.7.4

Re: non-space, paste, (???) character for inline results

[Nicolas Goaziou]

Hello,

Greg Minshall <minshall@acm.org> writes:

> one concern: if i essentially "revert" the changes in
> 7efa0f2879226695ad9b309c9263a4d1b5d79e89, call_ and src_ all work, but i
> get the ZERO WIDTH SPACE (ZSWP, \u200b) propagated into the resulting
> output file (.html, .tex). it doesn't seem to do any "harm", but, i find
> it disquieting (being an ASCII-type by birth, if not by current
> usage).

I don't want to revert 7efa0f2879226695ad9b309c9263a4d1b5d79e89 since it
gives more options than before.

You can, however, remove zero width spaces from output with an
appropriate filter, e.g., `org-export-filter-final-output-functions'.

Regards,

-- 
Nicolas Goaziou                                                0x80A93738

Re: non-space, paste, (???) character for inline results

[Greg Minshall]

Nico,

thanks for the reply.  i'd suggest reverting (most of) 7efa... so that
foocall_foo() *stays* as foocall_foo().  (i.e., put the "\\<" back in
front of "call_" and "sys_".)  otherwise, we have no (straight forward)
way (am i right?  sometimes my head hurts!) to get a plain
"foocall_foo()" in the output.

(whereas, with 7efa reverted, we can get "foocall_foo()" in the output
by writing exactly that, and, if we *really* want foo<RESULTS>, for
<RESULTS> == results of executing call_foo(), we write
foo<ZSWP>call_foo().)

thanks for the pointer to org-export-filter-final-output-functions.

cheers, Greg

Re: non-space, paste, (???) character for inline results

[Nicolas Goaziou]

Greg Minshall <minshall@acm.org> writes:

> thanks for the reply.  i'd suggest reverting (most of) 7efa... so that
> foocall_foo() *stays* as foocall_foo().  (i.e., put the "\\<" back in
> front of "call_" and "sys_".)  otherwise, we have no (straight forward)
> way (am i right?  sometimes my head hurts!) to get a plain
> "foocall_foo()" in the output.

Of course we do: just write 

  foocall<ZSWP>_foo()

or

  foocall_foo<ZSWP>()

etc.

Re: non-space, paste, (???) character for inline results

[Greg Minshall]

> Of course we do: just write 
> 
>   foocall<ZSWP>_foo()
> 
> or
> 
>   foocall_foo<ZSWP>()

!!! :)

(but, seems less intuitive.  maybe my math/CS brainwashing, liking to
have lexical elements, etc.; that part of me would still vote for
reverting.)

Re: non-space, paste, (???) character for inline results

[Nicolas Goaziou]

Greg Minshall <minshall@acm.org> writes:

>> Of course we do: just write 
>> 
>>   foocall<ZSWP>_foo()
>> 
>> or
>> 
>>   foocall_foo<ZSWP>()
>
> !!! :)
>
> (but, seems less intuitive.  maybe my math/CS brainwashing, liking to
> have lexical elements, etc.; that part of me would still vote for
> reverting.)

Hmmm, you may well be right. Fair enough. I reverted it.

Thank you.

Re: non-space, paste, (???) character for inline results

[Greg Minshall]

> Hmmm, you may well be right. Fair enough. I reverted it.

thanks!