Re: syntax parsing of non-contiguous regions

Re: syntax parsing of non-contiguous regions

[Alexander Katovsky]

I'm afraid I'm being a little slow understanding you're suggestion.  
I've already defined comment-start and comment-end as '!' and '\n' 
respectively.  Also, I need all the syntax motion functions 
(forward-sexp, parse-partial-sexp et al) to treat the embedded code as a 
comment so that the embedded code does not disrupt syntax motion 
outside.  For example, suppose that my primary mode is for code 
consisting of named blocks with comments starting with '!' and ending 
with newline, and my embedded code is C.  Then we could have

named-block  ! some comment
{
    %{
        if(a != b){}
    }%
}

Then the syntax motion functions would completely ignore the embedded 
code, just as it would a comment.  So if point is before the first 
opening brace then, no matter what's inside %{}%, forward-sexp would 
place point at the last closing brace.  And all the other syntax 
functions would just 'work' as well!

I'd be very grateful if could explain in a little more detail exactly 
what the 'hide-or-ignore' functions that you suggest are and how they 
could be used to achieve this effect.

Thanks,
Alex

Re: syntax parsing of non-contiguous regions

[Andreas Röhler]

Alexander Katovsky wrote:
> I'm afraid I'm being a little slow understanding you're suggestion. 
> I've already defined comment-start and comment-end as '!' and '\n'
> respectively.  Also, I need all the syntax motion functions
> (forward-sexp, parse-partial-sexp et al) to treat the embedded code as
> a comment so that the embedded code does not disrupt syntax motion
> outside.  For example, suppose that my primary mode is for code
> consisting of named blocks with comments starting with '!' and ending
> with newline, and my embedded code is C.  Then we could have
>
> named-block  ! some comment
> {
>    %{
>        if(a != b){}
>    }%
> }
>
> Then the syntax motion functions would completely ignore the embedded
> code, just as it would a comment.  So if point is before the first
> opening brace then, no matter what's inside %{}%, forward-sexp would
> place point at the last closing brace.  And all the other syntax
> functions would just 'work' as well!
>
> I'd be very grateful if could explain in a little more detail exactly
> what the 'hide-or-ignore' functions that you suggest are and how they
> could be used to achieve this effect.
>
> Thanks,
> Alex
>
>
>
>

Below a test-implementation, where `forward-sexp' works  as expected:


(defun my-syntax-mode (arg &optional beg end)
  " "
  (interactive "p")
  (let ((beg (cond (beg beg)
                   ((region-active-p)
                    (region-beginning))
                   (t (point-min))))
        (end (cond (end end)
                   ((region-active-p)
                    (copy-marker (region-end)))
                   (t (point-max))))
        )
    (save-restriction
      (narrow-to-region beg end)
      (goto-char beg))
    (my-syntax-mode-intern arg beg end )
    (widen)))

(defun my-syntax-mode-intern (arg beg end)
 
  (let ((comment-start (concat comment-start "\\|%{"))
        (comment-end (concat comment-end"\|}%")))
    (forward-sexp)
      ))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

Mode was emacs-lisp, tested with

(defun foo (&optional beg end)
  " "
  (interactive "*")
  ;; (let ((beg (cond (beg beg)
  {
   %{
       if(a != b){}
   }%
}
           ((region-active-p)
            (region-beginning))
           (t (point-min))))
    (end (cond (end (copy-marker end))
           ((region-active-p)
            (copy-marker (region-end)))
           (t (copy-marker (point-max))))))
    (save-excursion
      (goto-char beg))
    (when (interactive-p) (message "%s %s" beg end))))

;;;;;;;;;;;;;;;;;;

Cursor starts behind   (interactive "*"), passes both comments.

So far

Andreas


 

syntax parsing of non-contiguous regions

[Alexander Katovsky]

Hi,

I want Emacs' syntax motion functions to ignore certain regions of the 
buffer; i.e. to correctly parse non-contiguous regions. This can be done 
effectively if you can define the region to ignore as a comment and set 
parse-sexp-ignore-comments variable to true.

Here's the problem. The primary mode has comments starting with '!' and 
ending with newline ('\n') and the buffer region I want ignored as a 
comment starts with "%{" and ends with "}%". However, I cannot see any 
way to define these both as comments. The mechanism to cope with 
multi-character comment delimiters in the syntax table is too specific 
to C to use here. Does anyone have any other suggestions, 
text-properties, for example?

Thanks,
Alex

Re: syntax parsing of non-contiguous regions

[Andreas Politz]

Emacs offers the possibility of setting the character-syntax on the fly.

(info "(elisp) Setting Syntax Properties")

Out of boredom, I actually tried to implement something like this.

(defun foo-mode ()
  (interactive)
  (kill-all-local-variables)
  (set-syntax-table
   (let ((tb (make-syntax-table)))
     (modify-syntax-entry ?{ ". 1" tb)
     (modify-syntax-entry ?% ". 23" tb)
     (modify-syntax-entry ?} ". 4" tb)
     tb))

  (setq font-lock-defaults
        '(nil nil nil nil nil
              (font-lock-syntactic-keywords
               .
               ((foo-find-other-comment
                 ; generic comment syntax prohibits regular comments
                 ; inside it
                 (1 "!")                
                 (2 "!")))))))

(defun foo-find-other-comment (limit)
  "Starting at point, find the next occurence of '!' not inside a
string or comment."
  (let (success)
    (while (and (not success)
                (re-search-forward
                 "\\(!\\).*\\(\n?\\)" limit t))
      (setq success (let ((st (syntax-ppss (match-beginning 0))))
                      (not (or (nth 4 st)     ;comment
                               (nth 5 st))))) ;string
      (unless (eobp)
        (forward-char))
      (when success
        (goto-char (match-end 0))))
    success))



-ap

Re: syntax parsing of non-contiguous regions

[Andreas Röhler]

Alexander Katovsky wrote:
> Hi,
>
> I want Emacs' syntax motion functions to ignore certain regions of the
> buffer; i.e. to correctly parse non-contiguous regions. This can be
> done effectively if you can define the region to ignore as a comment
> and set parse-sexp-ignore-comments variable to true.
>
> Here's the problem. The primary mode has comments starting with '!'
> and ending with newline ('\n') and the buffer region I want ignored as
> a comment starts with "%{" and ends with "}%". However, I cannot see
> any way to define these both as comments. The mechanism to cope with
> multi-character comment delimiters in the syntax table is too specific
> to C to use here. Does anyone have any other suggestions,
> text-properties, for example?
>
> Thanks,
> Alex
>
>
>
>
>

Hi,

AFAIK: however you set the syntax of chars:
`forward-same-syntax' will stop at next syntax-change,
for example at a whitespace character inside a comment.

Don't think setting `parse-sexp-ignore-comments'
variable to true will change this, as it is set here that way
and doesn't hinder motion into comments.

Maybe can you tell more, what you are going to achieve,
what the issue behind is?

Cheers
Andreas

--
https://code.launchpad.net/s-x-emacs-werkstatt/
http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/

Re: syntax parsing of non-contiguous regions

[Alexander Katovsky]

Hi,

Thanks for your reply.  The reason that I want to do this is to make a 
major mode that supports embedded code (i.e. two major  modes).  I have 
a strategy for doing this that would be well suited to my specific 
problem and is different from the multi-mode implementations I have 
seen.  The new mode will be derived from the primary mode.  The 
fontification in the primary mode will provide a hook that the derived 
mode can use to fontify the embedded code.  This will work very 
elegantly if I can define the embedded code as a comment in the derived 
mode.  In this way, the parent mode will simply ignore the embedded code 
entirely, so that it will not interfere in any way with the primary 
code, and I can decide what to do with it later.

Re: syntax parsing of non-contiguous regions

[Andreas Röhler]

Alexander Katovsky wrote:
> Hi,
>
> Thanks for your reply.  The reason that I want to do this is to make a
> major mode that supports embedded code (i.e. two major  modes).  I
> have a strategy for doing this that would be well suited to my
> specific problem and is different from the multi-mode implementations
> I have seen.  The new mode will be derived from the primary mode.  The
> fontification in the primary mode will provide a hook that the derived
> mode can use to fontify the embedded code.  This will work very
> elegantly if I can define the embedded code as a comment in the
> derived mode.  In this way, the parent mode will simply ignore the
> embedded code entirely, so that it will not interfere in any way with
> the primary code, and I can decide what to do with it later.
>
>

ok. IMHO you don't need syntax-stuff installing a new comment-style. New
comment-settings inside a
let should work:

  (let ((comment-start "%{")
        (comment-end "}%"))
    MY-HIDE-or-IGNORE- functions

In case your comment-move-functions are buggy:  try
comment-lor.el


Andreas

--
https://code.launchpad.net/s-x-emacs-werkstatt/
http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/

Re: syntax parsing of non-contiguous regions

[Lennart Borgman]

On Mon, Sep 21, 2009 at 9:28 PM, Alexander Katovsky
<alexander.katovsky@googlemail.com> wrote:
> Hi,
>
> Thanks for your reply.  The reason that I want to do this is to make a major
> mode that supports embedded code (i.e. two major  modes).  I have a strategy
> for doing this that would be well suited to my specific problem and is
> different from the multi-mode implementations I have seen.  The new mode
> will be derived from the primary mode.  The fontification in the primary
> mode will provide a hook that the derived mode can use to fontify the
> embedded code.

This looks rather similar to what MuMaMo does, but it does not use
comments for this. MuMaMo divides the buffer into major mode chunks.
This chunks are fontified by different major modes.

I am not sure I understand why you do not want to use MuMaMo here. Can
you please explain what you are missing?