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

2018-02-05 Thread Greg Minshall
> Hmmm, you may well be right. Fair enough. I reverted it.

thanks!



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

2018-02-03 Thread Nicolas Goaziou
Greg Minshall  writes:

>> Of course we do: just write 
>> 
>>   foocall_foo()
>> 
>> or
>> 
>>   foocall_foo()
>
> !!! :)
>
> (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: [O] non-space, paste, (???) character for inline results

2018-02-03 Thread Greg Minshall
> Of course we do: just write 
> 
>   foocall_foo()
> 
> or
> 
>   foocall_foo()

!!! :)

(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: [O] non-space, paste, (???) character for inline results

2018-02-03 Thread Nicolas Goaziou
Greg Minshall  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_foo()

or

  foocall_foo()

etc.



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

2018-02-03 Thread 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, for
 == results of executing call_foo(), we write
foocall_foo().)

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

cheers, Greg




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

2018-02-03 Thread Nicolas Goaziou
Hello,

Greg Minshall  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 Goaziou0x80A93738



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

2018-01-31 Thread Greg Minshall
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<> in the output,
one prefixes CALL_FOO() with *two* ZWSPs.

>From df94d943d085947212d96eddec9870d7dca0ea23 Mon Sep 17 00:00:00 2001
From: Greg Minshall 
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?\\

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

2018-01-31 Thread Nicolas Goaziou
Greg Minshall  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: [O] non-space, paste, (???) character for inline results

2018-01-31 Thread Kaushal Modi
On Wed, Jan 31, 2018 at 12:51 PM Kaushal Modi 
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


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

2018-01-31 Thread Kaushal Modi
On Wed, Jan 31, 2018 at 12:44 PM Greg Minshall  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


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

2018-01-31 Thread Greg Minshall
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

>From e0337aabb13fabcefbb0a9fd65e8d4c9bcd412ee Mon Sep 17 00:00:00 2001
From: Greg Minshall 
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 "#?\\From b032d0860431ff29e7136145605d4f3d981d5301 Mon Sep 17 00:00:00 2001
From: Greg Minshall 
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 "#?\\

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

2018-01-31 Thread Nicolas Goaziou
Greg Minshall  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: [O] non-space, paste, (???) character for inline results

2018-01-31 Thread Greg Minshall
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

>From e0337aabb13fabcefbb0a9fd65e8d4c9bcd412ee Mon Sep 17 00:00:00 2001
From: Greg Minshall 
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 "#?\\

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

2018-01-31 Thread Nicolas Goaziou
Hello,

Greg Minshall  writes:

> not wanting to look gift horses, etc., but i've a question.  if i
> understand the change correctly
> 
> - (looking-at "\\ + (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: [O] non-space, paste, (???) character for inline results

2018-01-30 Thread 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 "\\

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

2018-01-30 Thread Nicolas Goaziou
Hello,

Greg Minshall  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 Goaziou0x80A93738



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

2018-01-30 Thread 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: [O] non-space, paste, (???) character for inline results

2018-01-30 Thread Nicolas Goaziou
Hello,

Greg Minshall  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