Parens matching off in babel code block

Parens matching off in babel code block

[Lawrence Bottorff]

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

Wondering if you have seen this
<https://emacs.stackexchange.com/questions/50216/org-mode-code-block-parentheses-mismatch>
over
at emacs.stackexchange. Very puzzling why the parens mismatch in a babel
emacs-lisp block, but not anywhere else in Emacs.

LB

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

Re: Parens matching off in babel code block

[Berry, Charles]

> On May 1, 2019, at 7:56 PM, Lawrence Bottorff <borgauf@gmail.com> wrote:
> 
> Wondering if you have seen this over at emacs.stackexchange. Very puzzling why the parens mismatch in a babel emacs-lisp block, but not anywhere else in Emacs.

I don't know the details but this ECM might help:

#+begin_src emacs-lisp
  (> 1 2)
#+end_src

The right broken bracket matches the left parenthesis in org-mode, but not in a Lisp Interaction Mode buffer.

HTH

Chuck 

Re: Parens matching off in babel code block

[Lawrence Bottorff]

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

Not sure what you mean. This is the problem, i.e., just this code

#+begin_src emacs-lisp
  (> 1 2)
#+end_src

in an org file produces a parens mismatch, which, BTW, check-parens also
flags. Anywhere else (e.g., *scratch*) in Emacs this code produces no
mismatch.

On Thu, May 2, 2019 at 10:35 AM Berry, Charles <ccberry@ucsd.edu> wrote:

>
>
> > On May 1, 2019, at 7:56 PM, Lawrence Bottorff <borgauf@gmail.com> wrote:
> >
> > Wondering if you have seen this over at emacs.stackexchange. Very
> puzzling why the parens mismatch in a babel emacs-lisp block, but not
> anywhere else in Emacs.
>
> I don't know the details but this ECM might help:
>
> #+begin_src emacs-lisp
>   (> 1 2)
> #+end_src
>
> The right broken bracket matches the left parenthesis in org-mode, but not
> in a Lisp Interaction Mode buffer.
>
> HTH
>
> Chuck
>

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

Re: Parens matching off in babel code block

[Bruno BARBIER]

Hi Lawrence,

Lawrence Bottorff <borgauf@gmail.com> writes:

> Not sure what you mean. This is the problem, i.e., just this code
>
> #+begin_src emacs-lisp
>   (> 1 2)
> #+end_src
>
> in an org file produces a parens mismatch, which, BTW, check-parens also
> flags. Anywhere else (e.g., *scratch*) in Emacs this code produces no
> mismatch.
>
In an org buffer, '>' is a closing delimiter. In an elisp buffer (like
the *scratch* one), '>' is just a symbol (you can use the command
'describe-char' to have a description of the character at point).

In short, if I understand correctly, it's not supposed to work like you
expect; you need to edit the source block to do things that really
depend on the code source syntax (C-c ').

Bruno


> On Thu, May 2, 2019 at 10:35 AM Berry, Charles <ccberry@ucsd.edu> wrote:
>
>>
>>
>> > On May 1, 2019, at 7:56 PM, Lawrence Bottorff <borgauf@gmail.com> wrote:
>> >
>> > Wondering if you have seen this over at emacs.stackexchange. Very
>> puzzling why the parens mismatch in a babel emacs-lisp block, but not
>> anywhere else in Emacs.
>>
>> I don't know the details but this ECM might help:
>>
>> #+begin_src emacs-lisp
>>   (> 1 2)
>> #+end_src
>>
>> The right broken bracket matches the left parenthesis in org-mode, but not
>> in a Lisp Interaction Mode buffer.
>>
>> HTH
>>
>> Chuck
>>

Re: Parens matching off in babel code block

[Marco Wahl]

>> Not sure what you mean. This is the problem, i.e., just this code
>>
>> #+begin_src emacs-lisp
>>   (> 1 2)
>> #+end_src
>>
>> in an org file produces a parens mismatch, which, BTW, check-parens also
>> flags. Anywhere else (e.g., *scratch*) in Emacs this code produces no
>> mismatch.

> In an org buffer, '>' is a closing delimiter. In an elisp buffer (like
> the *scratch* one), '>' is just a symbol (you can use the command
> 'describe-char' to have a description of the character at point).

> In short, if I understand correctly, it's not supposed to work like you
> expect; you need to edit the source block to do things that really
> depend on the code source syntax (C-c ').

Using < and > as parenthesis in Org is questionable, I think.  Also this
behavior is not documented AFAICT.

What about removing this special?  Or does anyone enjoy this behavior?

Re: Parens matching off in babel code block

[Nicolas Goaziou]

Hello,

Marco Wahl <marcowahlsoft@gmail.com> writes:

> Using < and > as parenthesis in Org is questionable, I think.  

In Org syntax, < and > often come in pair (timestamps, some links,
targets, radio targets). There is at least some interest in the current
behaviour.

> Also this behavior is not documented AFAICT.

I don't think you can document every single detail. Even if it was
possible, it wouldn't be desirable.

> What about removing this special?  Or does anyone enjoy this behavior?

This needs to be carefully tested and weighted.

Regards,

-- 
Nicolas Goaziou

Re: Parens matching off in babel code block

[Lawrence Bottorff]

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

Well, at least there is a sane explanation. Ironically, I was also about to
complain about all my loose ">"s getting flagged. So they are related!
Would there be a way to make an exception for < and > inside of actual code
forms? Languages need them for "greater than" and "less than".

On Thu, May 2, 2019 at 4:39 PM Nicolas Goaziou <mail@nicolasgoaziou.fr>
wrote:

> Hello,
>
> Marco Wahl <marcowahlsoft@gmail.com> writes:
>
> > Using < and > as parenthesis in Org is questionable, I think.
>
> In Org syntax, < and > often come in pair (timestamps, some links,
> targets, radio targets). There is at least some interest in the current
> behaviour.
>
> > Also this behavior is not documented AFAICT.
>
> I don't think you can document every single detail. Even if it was
> possible, it wouldn't be desirable.
>
> > What about removing this special?  Or does anyone enjoy this behavior?
>
> This needs to be carefully tested and weighted.
>
> Regards,
>
> --
> Nicolas Goaziou
>
>

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

Re: Parens matching off in babel code block

[Marco Wahl]

Hi,

>> Using < and > as parenthesis in Org is questionable, I think.  
>
> In Org syntax, < and > often come in pair (timestamps, some links,
> targets, radio targets). There is at least some interest in the current
> behaviour.

Yes, okay.

>> Also this behavior is not documented AFAICT.
>
> I don't think you can document every single detail. Even if it was
> possible, it wouldn't be desirable.

Agreed.  My statement was thought as a pointer to the possibility to
drop the <>-parenthesis-feature without touching the documentation.

>> What about removing this special?  Or does anyone enjoy this behavior?
>
> This needs to be carefully tested and weighted.

Yes, agreed.

Currently I run Org mode without the <> parenthesis using the patch:

modified   lisp/org.el
-  (modify-syntax-entry ?< "(>")
-  (modify-syntax-entry ?> ")<")
+  ;; (modify-syntax-entry ?< "(>")
+  ;; (modify-syntax-entry ?> ")<")

Up to now I don't miss the <> parenthesis.  But this is just me.


Ciao,
-- 
Marco

Re: Parens matching off in babel code block

[Fraga, Eric]

On Thursday,  2 May 2019 at 21:11, Lawrence Bottorff wrote:
> Well, at least there is a sane explanation. Ironically, I was also about to
> complain about all my loose ">"s getting flagged. So they are related!
> Would there be a way to make an exception for < and > inside of actual code
> forms? Languages need them for "greater than" and "less than".

I have the following in my org mode customization:

    (modify-syntax-entry ?< ".")
    (modify-syntax-entry ?> ".")

as many of my org files have these symbols not as paren but as operators.
-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.2.2-290-g300f15

Re: Parens matching off in babel code block

[John Kitchin]

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

This issue also pops up in python blocks for me alot.  For example, here is
a place where it does not work as it should.

[image: image.png]
John

-----------------------------------
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu



On Fri, May 3, 2019 at 5:24 AM Fraga, Eric <e.fraga@ucl.ac.uk> wrote:

> On Thursday,  2 May 2019 at 21:11, Lawrence Bottorff wrote:
> > Well, at least there is a sane explanation. Ironically, I was also about
> to
> > complain about all my loose ">"s getting flagged. So they are related!
> > Would there be a way to make an exception for < and > inside of actual
> code
> > forms? Languages need them for "greater than" and "less than".
>
> I have the following in my org mode customization:
>
>     (modify-syntax-entry ?< ".")
>     (modify-syntax-entry ?> ".")
>
> as many of my org files have these symbols not as paren but as operators.
> --
> Eric S Fraga via Emacs 27.0.50, Org release_9.2.2-290-g300f15
>

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

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

Re: Parens matching off in babel code block

[Marco Wahl]

"Fraga, Eric" <e.fraga@ucl.ac.uk> writes:

> On Thursday,  2 May 2019 at 21:11, Lawrence Bottorff wrote:
>> Well, at least there is a sane explanation. Ironically, I was also about to
>> complain about all my loose ">"s getting flagged. So they are related!
>> Would there be a way to make an exception for < and > inside of actual code
>> forms? Languages need them for "greater than" and "less than".
>
> I have the following in my org mode customization:
>
>     (modify-syntax-entry ?< ".")
>     (modify-syntax-entry ?> ".")
>
> as many of my org files have these symbols not as paren but as operators.

I'll follow your lead and add the lines

	(add-hook
	 'org-mode-hook
	 (lambda ()
	    (modify-syntax-entry ?< ".")
	    (modify-syntax-entry ?> ".")))

to my config.


Thanks,
-- 
Marco