Org-mode mailing list
 help / color / mirror / Atom feed
* Re: Font lock in org+elisp confused with ?\[
       [not found] <AM9PR09MB497740C52C6EE5A5680C9D84967B9@AM9PR09MB4977.eurprd09.prod.outlook.com>
@ 2021-04-02  4:23 ` Tim Cross
  2021-04-02 13:03   ` John Kitchin
  0 siblings, 1 reply; 4+ messages in thread
From: Tim Cross @ 2021-04-02  4:23 UTC (permalink / raw)
  To: Arthur Miller; +Cc: Org-mode, Emacs developers

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

I'm forwarding this to the emacs-orgmode list as this is something org
maintainers probably need to see.

On Thu, 1 Apr 2021 at 15:43, Arthur Miller <arthur.miller@live.com> wrote:

>
> Is it me or is it a bug?
>
> When in org mode in an elisp block, this seems to confuse syntax
> checker:
>
> #+begin_src emacs-lisp
> (progn
>   (if (= (following-char) ?\])
>       (forward-char -1))
>   )
> #+end_src
>
> Identation seems to think it is one level extra, and it also shows as
> error. Same of course when testing for ?\[.
>
> It does evaluate correctly. Ordinary elisp buffer does not have problem
> with this, only when in code blocks in org-mode or elisp mode.I can send
> in some screenshot with errors if needed.
>
>
>

-- 
regards,

Tim

--
Tim Cross

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Font lock in org+elisp confused with ?\[
  2021-04-02  4:23 ` Font lock in org+elisp confused with ?\[ Tim Cross
@ 2021-04-02 13:03   ` John Kitchin
  2021-04-02 22:59     ` Tom Gillespie
  2021-04-03 18:38     ` Arthur Miller
  0 siblings, 2 replies; 4+ messages in thread
From: John Kitchin @ 2021-04-02 13:03 UTC (permalink / raw)
  To: Tim Cross; +Cc: Org-mode, Arthur Miller, Emacs developers

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

This is related to the issues with <> in src blocks. [ and ] have open and
close syntactical meanings like < and > do in org files. A similar solution
as found in
https://emacs.stackexchange.com/questions/50216/org-mode-code-block-parentheses-mismatch
seems to work to fix it.

John

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



On Fri, Apr 2, 2021 at 12:24 AM Tim Cross <theophilusx@gmail.com> wrote:

> I'm forwarding this to the emacs-orgmode list as this is something org
> maintainers probably need to see.
>
> On Thu, 1 Apr 2021 at 15:43, Arthur Miller <arthur.miller@live.com> wrote:
>
>>
>> Is it me or is it a bug?
>>
>> When in org mode in an elisp block, this seems to confuse syntax
>> checker:
>>
>> #+begin_src emacs-lisp
>> (progn
>>   (if (= (following-char) ?\])
>>       (forward-char -1))
>>   )
>> #+end_src
>>
>> Identation seems to think it is one level extra, and it also shows as
>> error. Same of course when testing for ?\[.
>>
>> It does evaluate correctly. Ordinary elisp buffer does not have problem
>> with this, only when in code blocks in org-mode or elisp mode.I can send
>> in some screenshot with errors if needed.
>>
>>
>>
>
> --
> regards,
>
> Tim
>
> --
> Tim Cross
>
>

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Font lock in org+elisp confused with ?\[
  2021-04-02 13:03   ` John Kitchin
@ 2021-04-02 22:59     ` Tom Gillespie
  2021-04-03 18:38     ` Arthur Miller
  1 sibling, 0 replies; 4+ messages in thread
From: Tom Gillespie @ 2021-04-02 22:59 UTC (permalink / raw)
  To: John Kitchin; +Cc: Tim Cross, Org-mode, Arthur Miller, Emacs developers

Reposting my reply to the emacs-devel thread here as well. The hack I
mention that has performance issues was derived from John's solution
for the <> issue (though the performance issues are all of my own
creation). Best,
Tom

This is a known issue with org babel blocks. It is due to the fact
that org babel translates the font locking for the language but not
the syntax propertization. Another frequent cause is the bash case
statement. The end result is that unmatched parens leak out from the
babel blocks and wreak havoc elsewhere in the org file unless you
balance out the parens e.g. in a comment. I have a hacked fix for
this, but it has horrible performance, especially with line numbers
enabled. I think that a proper solution would run arbitrary syntax
propertization on subsets of a buffer without having to continually
check where those subsets start or end.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Font lock in org+elisp confused with ?\[
  2021-04-02 13:03   ` John Kitchin
  2021-04-02 22:59     ` Tom Gillespie
@ 2021-04-03 18:38     ` Arthur Miller
  1 sibling, 0 replies; 4+ messages in thread
From: Arthur Miller @ 2021-04-03 18:38 UTC (permalink / raw)
  To: John Kitchin; +Cc: Tim Cross, Org-mode, Emacs developers

John Kitchin <jkitchin@andrew.cmu.edu> writes:

> This is related to the issues with <> in src blocks. [ and ] have open and close syntactical meanings like < and > do in org files. A similar solution as found in
> https://emacs.stackexchange.com/questions/50216/org-mode-code-block-parentheses-mismatch seems to work to fix it.

Indeed, the code from SX works, I took the simpler version and converted
it to work with square brackets:

#+begin_src emacs-lisp
             (defun org-mode-sqbr-syntax-fix (start end)
               (when (eq major-mode 'org-mode)
                 (save-excursion
                   (goto-char start)
                   (while (re-search-forward "[]\\[]" end t)
                     (when (get-text-property (point) 'src-block)
                       ;; This is a ?[ or ?] in an org-src block
                       (put-text-property (point) (1- (point))
                                          'syntax-table (string-to-syntax "_")))))))

             (defun org-setup-sqbr-syntax-fix ()
               "Setup for characters ?[ and ?] in source code blocks.
  Add this function to `org-mode-hook'."
               (setq syntax-propertize-function 'org-mode-sqbr-syntax-fix)
               (syntax-propertize (point-max)))

             (add-hook 'org-mode-hook 'org-setup-sqbr-syntax-fix)
#+end_src

I have confirmed that code runs when I load my org file, but there seems
to be something else than that callback involed, later on, evaluating
and changing those properties back. I still see same error in the
babel-block. However when I run fix explicitly on that code block (I
converted it to interactive "r" for test), then syntax is fine. So it
seems there is some other callback involved.

Sorry little bit late answer, I thought I sent this a day ago or so, but
apparently I didn't.

Thanks for the help.


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-04-03 18:39 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <AM9PR09MB497740C52C6EE5A5680C9D84967B9@AM9PR09MB4977.eurprd09.prod.outlook.com>
2021-04-02  4:23 ` Font lock in org+elisp confused with ?\[ Tim Cross
2021-04-02 13:03   ` John Kitchin
2021-04-02 22:59     ` Tom Gillespie
2021-04-03 18:38     ` Arthur Miller

Org-mode mailing list

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://orgmode.org/list/0 list/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 list list/ https://orgmode.org/list \
		emacs-orgmode@gnu.org
	public-inbox-index list

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.emacs.orgmode
	nntp://news.gmane.io/gmane.emacs.orgmode


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git