Martin Schwamberger writes: > Hi Paul, > > Berndl, Klaus wrote: > > Here is a better way to determine the syntactiy context of current point, means > > if point stays within a line-comment, block-comment or within a string. IMHO this > > is more robust than jde-line-has-incomplete-string...and uses well proved > > Emacs-concepts for this instead of fiddling with some regexps and increasing > > numbers ;-) > > > > (defun syntactic-context () > > "Check in which syntactic context point is. Return nil if no special context > > meaning, otherwise 'string if within a string, 'comment if within a > > line-comment and 'block-comment if within a block-comment." > > (let* ((beg (save-excursion > > (beginning-of-defun) > > (point))) > > (state (save-excursion > > (parse-partial-sexp beg (point))))) > > (cond > > ((nth 3 state) 'string) > > ((nth 4 state) (if (member major-mode > > '(c-mode c++-mode java-mode jde-mode)) > > (if (nth 7 state) 'comment 'block-comment) > > 'comment)) > > (t nil)))) > > > > This function returns 'string if point is within a string - so also when point is > > at the end of an unterminated string. > > In that situation a newline-command should insert a (java)string terminator and > > so on ... As already done by the code of this thread. This has the side-effect > > that when point stays within a terminated string a newline-command breaks this > > string by adding a new terminator behind the break...so the smart newline-command > > does not only for unterminated strings the right thing but also for terminated. > > > > jde-parse-comment-or-quoted-p doen't work reliable. > I propose to reimplement this function using parse-partial-sexp. > Since I've already made changes on jde-parse.el, I could do > this, if you agree. >
I do. Thanks. > > > > Off topic: JDEE does this also with all the template-stuff - where IMHO somehow > > cumbersomely is specified if a newline after a brace or not etc... all this could > > be done more nifty with mechanism of cc-mode and tempo, so the user specifies > > with cc-mode when he wants newlines before or after praces etc. and tempo uses > > this informations instead of introducing new options by JDEE so the user has to > > customize the same thing at differrent places. Yes. I agree this approach would be much more elegant and I'd appreciate your doing it. Regards, Paul > > > > Since I do already work on the templates, > I could move the k&r stuff to a function (or macro). > This would finally allow to change the way it is implemented > at one single place. > > Regards, > > Martin
