Adrian Aichner <adrian(a)xemacs.org> writes:
Yoshiki> Except that point, I agree it is a good change.
Would you
Yoshiki> care to post a patch to xemacs-patches?
It should probably also be submitted upstream to
Ilya Zakharevich <ilya(a)math.mps.ohio-state.edu>
Is he still maintaining cperl-mode? I thought he was too
busy to maintain it and XEmacs Development Team took over
the maintenance. Maintainer comment in cperl-mode.el agrees
with what I thought.
Vaclav Barta <vbar(a)comp.cz> writes:
You mean like (setq fill-paragraph-function
'cperl-fill-paragraph) ? That doesn't work (M-q still calls
fill-paragraph-or-region)... Perhaps I'm putting it in the wrong
place (I certainly don't understand how cperl-mode initializes
itself), but uncommenting the (cperl-define-key "\M-q"
'cperl-fill-paragraph) in the same place (cperl-mode-map
initialization) works OK...
Did you eval setq in scratch buffer? Then it won't work.
You have to eval it in a buffer because
fill-paragraph-function is a buffer local variable. Switch
buffer to where you are visiting perl program and then type
M-: (setq fill-paragraph-function 'cperl-fill-paragraph)
It is OK that M-q calls fill-paragraph-or-region. If you
look at the doc string of fill-paragraph-function, you'll
find this:
Documentation:
Mode-specific function to fill a paragraph, or nil if there is none.
If the function returns nil, then `fill-paragraph' does its normal work.
> Except that point, I agree it is a good change. Would you
> care to post a patch to xemacs-patches?
You'll have far more trouble explaining to me how to make a xemacs
patch than making the one-line change yourselves - but if you
insist...:-)
The suggested change is to call
(setq fill-paragraph-function 'cperl-fill-paragraph)
inside cperl-mode function.
Then take the unified diff between old and new files by
using diff -u. You also need to write the changelog for it
(see xemacs-patches and other ChangeLog for how to write it)
and send it to xemacs-patches. It is also helpful to add
small sample perl file which is formatted incorrectly before
the change and will be formatted correctly after the change.
It is not mandatory but it will significantly speed up the
review process.
If all goes well, Steve Youngs will apply the patch and
release a new package.
Even if it is a single line change, it is always good to
have more people involved in the development. Also, if you
add test cases to a patch, it will make developer's life
easier because he/she won't need to write test case and see
the change is working correctly.
--
Yoshiki Hayashi