> I think for now I will use the same workaround.
I'd urge you to try and find a way to make it work without such
a workaround.
I definitely will. I am just using the work around for testing.
>> Yes. I suggest you submit a bug report for this bug.
> I will put some time into this and see if I can come up with a patch
> before flagging it as a bug.
Once you get it to work without the above workaround, you'll be able to
write a much better bug report.
Yes, and hopefully I can come up with a patch to improve the behavior as well.
>> To work properly, beginning/end-of-defun need to know whether the
>> starting point is inside a defun or between defuns.
Calling beginning-of-defun-function followed by end-of-defun-function
(and comparing the resulting position to the start position) should be
sufficient to let you know whether or not you're inside the function
whose definition starts most closely before point.
Hmm. In sh-mode `beginning-of-defun-function' is nil and in the example below, calling `end-of-defun-function' with M-: (funcall end-of-defun-function) brings point to fi and not the end of the function.
function foo {
if [[ $1 > 0 ]]; then
return 24
else
return 42
echo "Hello from foo"
}
In the example above, C-M-a and C-M-e do the right thing. However, in the presence of nested functions, C-M-a and C-M-e only navigate over top-level functions. For example:
function foo {
function bar {
echo "Hello from bar"
}
if [[ $1 > 0 ]]; then
return 24
else
return 42
echo "Hello from foo"
}
C-M-a/e brings point to beginning/end of foo even when point was inside bar and M-: (funcall end-of-defun-function) brings point to after o in echo.
If I define beginning/end-of-defun-function with the functions I wrote, the behavior I intended happens (bringing point to bar in the example above if point was inside bar).
--
João Paulo L. de Carvalho
Ph.D Computer Science | IC-UNICAMP | Campinas , SP - Brazil
Postdoctoral Research Fellow | University of Alberta | Edmonton, AB - Canada