Simon Wright <[email protected]> writes:
> As far as I can see the current code is
>
> indent := indentation of previous keyword;
> prev-indent := nil;
> next-indent := nil;
> if ada-indent-comment-gnat then
> if indent is a multiple of ada-indent
> then
> indent := indent;
> else
> indent previous line;
> prev-indent := indentation-of-previous-line;
> if indent = prev-indent
> then
> indent := indent;
> else
> indent next line;
> next-indent := indentation-of-next-line;
> if indent = next-indent
> then
> indent := indent;
> else
> if prev-indent /= nil or next-indent /= nil then
> indent := floor (indent, ada-indent);
> end if;
> end if;
> end if;
> end if;
> else
> indent := indent;
> end if;
>
> which has several problems.
>
> First, the initial calculated value of indent is almost bound to be a
> multiple of ada-indent, so most of the rest of the code won't have any
> effect. I don't think this check is actually necessary? (removing it
> doesn't seem to make any difference).
There were a couple places where it did, which is why I added
ada-indent-comment-gnat.
In test/ada_mode-conditional_expressions.adb, which sets
ada-indent-comment-gnat: t in the Local Variables:
K :=
(case Bounded (K) is
when -1 => 42,
when 0 => 41,
when 1 =>
(if J > 42
-- comment indented as code (ada-indent-broken)
then 44
else 45));
(there's a FIXME: in that comment about this, which I should have
deleted)
With ada-indent-comment-gnat false, this becomes:
(if J > 42
-- comment indented as code (ada-indent-broken)
then 44
which does not pass the gnat checks.
ada-mode-parens.adb also sets ada-indent-comment-gnat: t, but changing
that makes no difference in that file. I must have changed the code that
needed it. Or maybe this is verifying that the algorithm doesn't screw
up otherwise normal code.
> Second, that "floor (indent, ada-indent)" can't be right; you'd think
> it'd be something like "min (prev-indent, next-indent)".
since prev-indent and next-indent are both nil here, that can't be right
either. This branch of the logic is for corner cases that the other
branches don't handle. I should have put a comment there as to why I
thought floor was the right function. I'm guessing the intent was to do
something (other than throw an error) that would stand out, so it could
be corrected.
> Third, we'll only get to this point if neither prev-indent or
> next-indent is equal to the initial calculated indent, which seems
> unlikely?
Yes; but that means it will occur sometime. There doesn't seem to be an
actual test case for it.
> (I don't have a lot of confidence in my translation of the elisp :-)
Looks ok.
>> It would also make sense to match the behavior of GPS; I don't currently
>> have that installed to check.
>
> GPS has two switches: "Indent comments" and "Align comments on
> keywords". I couldn't work out the effect of the first (if any); the
> second aligns comments after (some) keywords with the keyword.
>
> I don't think either of these will do what Piotr wants.
The question is how does it indent his test code, with all four settings
of those switches.
--
-- Stephe
_______________________________________________
Emacs-ada-mode mailing list
[email protected]
http://host114.hostmonster.com/mailman/listinfo/emacs-ada-mode_stephe-leake.org
