GNU bug report logs -
#17895
24.3.91; electric-indent-mode not quite right with comments in fortran-mode
Previous Next
Reported by: "Roland Winkler" <winkler <at> gnu.org>
Date: Tue, 1 Jul 2014 21:32:01 UTC
Severity: minor
Tags: wontfix
Found in version 24.3.91
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17895 in the body.
You can then email your comments to 17895 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#17895
; Package
emacs
.
(Tue, 01 Jul 2014 21:32:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Roland Winkler" <winkler <at> gnu.org>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 01 Jul 2014 21:32:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
emacs -Q
insert a multiline comment while editing a file with fortran-mode
expected behavior (= emacs 24.3): typing RET (bound to newline)
inserts a newline and puts point at column 0 of the new line
actual behavior: the new line is indented to column 6
A similar problem exists with multiline statements requiring
fortran-continuation-string in column 5.
I do not see the benefit of this new behavior in the context of
fortran-mode. Maybe electric-indent-chars should be locally bound to
nil in fortran-mode.
PS: It seems to me that in fortran-mode the command
indent-for-tab-command bound to TAB is better suited to provide the
proper indentation *after* typing, say, fortran-comment-line-start
or fortran-continuation-string in column 0 of a new line.
In GNU Emacs 24.3.91.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.4.2)
of 2014-05-12 on regnitz
Windowing system distributor `The X.Org Foundation', version 11.0.11103000
System Description: Ubuntu 12.04.4 LTS
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#17895
; Package
emacs
.
(Tue, 01 Jul 2014 22:48:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 17895 <at> debbugs.gnu.org (full text, mbox):
[ Don't know enough about Fortran to know what is "insert a multiline
comment" in this context, neither do I know what is a "multiline
statement" or why it would "require fortran-continuation-string", so
I'll skip this part of your bug-report. Presumably Glenn will be able
to give you a more useful answer in this area. ]
> PS: It seems to me that in fortran-mode the command
> indent-for-tab-command bound to TAB is better suited to provide the
> proper indentation *after* typing, say, fortran-comment-line-start
> or fortran-continuation-string in column 0 of a new line.
Maybe a way to fix this problem, then, would be to make fortran's
indent-line-function indent to column 0 when called on an empty line in
one of those contexts.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#17895
; Package
emacs
.
(Tue, 01 Jul 2014 23:39:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 17895 <at> debbugs.gnu.org (full text, mbox):
"Roland Winkler" wrote:
> emacs -Q
> insert a multiline comment while editing a file with fortran-mode
But Fortran doesn't have multi-line comments. :)
I know what you mean though, you mean that the desired indentation of
the new line isn't known in advance, because it depends on what you write.
Other modes, such as Python, have similar issues.
There, TAB cycles between possible indent positions.
I don't think I see the point in adding something like that for
fixed-format Fortran though.
> A similar problem exists with multiline statements requiring
> fortran-continuation-string in column 5.
I don't see the issue here.
Previously you would have to enter: RET SPC SPC SPC SPC SPC $
or: RET TAB DEL $
or: RET $ TAB
The 1st is inefficient.
The 2nd is replaced by: RET DEL $ (less typing)
The 3rd still works.
> I do not see the benefit of this new behavior in the context of
> fortran-mode. Maybe electric-indent-chars should be locally bound to
> nil in fortran-mode.
Seems like a sledgehammer solution, just for the sake of "C" comments.
Even g77 supports "!" comments.
The new method is less typing on average, unless you write more "C"
comments than code.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#17895
; Package
emacs
.
(Tue, 01 Jul 2014 23:50:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 17895 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier wrote:
> [ Don't know enough about Fortran to know what is "insert a multiline
> comment" in this context
AFAIK, there is no such thing as "multiline comments" in Fortran.
I assume he means he has typed:
C this is a comment
Then he presses RET and wants to write more comments, but point gets
indented to column 6 instead. It's impossible for Fortran mode to know
if he was going to write code (column 6) or a comment (column 0). I
could say the same thing about pressing RET after a code line.
> neither do I know what is a "multiline statement" or why it would
> "require fortran-continuation-string"
If you want to write a continued code line, you put eg a "$" in column 5
of the new line. There's no marker in the previous line, so again it is
impossible for Fortran mode to know that's what you intend when you
press RET.
> Maybe a way to fix this problem, then, would be to make fortran's
> indent-line-function indent to column 0 when called on an empty line in
> one of those contexts.
It is impossible for it to know, as I hopefully explain above.
I really don't think that Fortran mode can do anything here.
The new behavior is different to the old one, but I think it will be a
net win in terms of fewer keypresses in most situations.
(Everyone should use free-format Fortran, where these problems were all
solved 20+ years ago!)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#17895
; Package
emacs
.
(Wed, 02 Jul 2014 01:18:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 17895 <at> debbugs.gnu.org (full text, mbox):
> Other modes, such as Python, have similar issues.
Actually, I think it's different: the problem with Python is that even
once the line is fully written, python-mode can't always decide where to
indent it, because there are several valid choices (and they don't mean
the same thing).
Instead, the problem here seems to only affect empty lines (i.e. lines
where the text hasn't been written yet), and this problem affects
many/most modes.
But I guess if the first non-whitespace char is a capital C,
fortran-mode has a similar problem to python-mode in that it can't know
for sure if the line should be assumed to be a comment (and go to
column-0) or to be some instruction that happens to start with a capital
C (and should go to some further column).
> or: RET $ TAB
And adding $ to electric-indent-chars would even save you from typing
this TAB (which doesn't mean that's what fortran-mode should do, tho.
I have the impression that this kind of old-style Fortran is fairly rare
nowadays).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#17895
; Package
emacs
.
(Wed, 02 Jul 2014 01:52:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 17895 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier wrote:
> Instead, the problem here seems to only affect empty lines (i.e. lines
> where the text hasn't been written yet)
(How do you type RET and have text already written on the new line...?)
> , and this problem affects many/most modes.
Oh duh, of course.
if foo; then
...
... when will endif appear...
... who knows...
endif # oh here it is
> But I guess if the first non-whitespace char is a capital C,
> fortran-mode has a similar problem to python-mode in that it can't know
> for sure if the line should be assumed to be a comment (and go to
> column-0) or to be some instruction that happens to start with a capital
> C (and should go to some further column).
Yep. (CHARACTER for example.)
So I don't really see that there is anything to do here.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#17895
; Package
emacs
.
(Wed, 02 Jul 2014 01:59:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 17895 <at> debbugs.gnu.org (full text, mbox):
Glenn Morris wrote:
>> Instead, the problem here seems to only affect empty lines (i.e. lines
>> where the text hasn't been written yet)
>
> (How do you type RET and have text already written on the new line...?)
Wow, I am unusually slow today! :)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#17895
; Package
emacs
.
(Wed, 02 Jul 2014 02:16:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 17895 <at> debbugs.gnu.org (full text, mbox):
>> Instead, the problem here seems to only affect empty lines (i.e. lines
>> where the text hasn't been written yet)
> (How do you type RET and have text already written on the new line...?)
When you hit RET in the middle of a line, of course.
And of course electric-indent-mode doesn't only trigger when you hit RET
(and for other keys, there'll usually be text on the current line), and
half the work of electric-indent-mode when triggered by RET is to
reindent the line where the RET was inserted (i.e. the "previous" line),
which is often/usually not empty either.
> So I don't really see that there is anything to do here.
Agreed,
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#17895
; Package
emacs
.
(Wed, 02 Jul 2014 20:56:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 17895 <at> debbugs.gnu.org (full text, mbox):
On Tue Jul 1 2014 Glenn Morris wrote:
> Even g77 supports "!" comments.
For existing code "!" is not always an adequate choice.
> (Everyone should use free-format Fortran, where these problems
> were all solved 20+ years ago!)
All this is obviously not about new code, but it is about
maintaining existing code.
(Also, that's why Emacs comes with fortran-mode and f90-mode. They
serve different needs!)
I completely agree that in a perfect world rewriting the old code is
the way to go. But that's not always possible. I am pretty sure
that such code will still be around and used happily twenty years
from now.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#17895
; Package
emacs
.
(Wed, 02 Jul 2014 21:04:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 17895 <at> debbugs.gnu.org (full text, mbox):
"Roland Winkler" wrote:
>> (Everyone should use free-format Fortran, where these problems
>> were all solved 20+ years ago!)
>
> All this is obviously not about new code, but it is about
> maintaining existing code.
> (Also, that's why Emacs comes with fortran-mode and f90-mode. They
> serve different needs!)
I know, I know.
I was just trying to give the bug-gnu-emacs audience who is not familiar
with Fortran an impression of the language based on something that is not
25 years obsolete.
Do you have any concrete suggestions for changing Emacs's fortran-mode
in light of this report? I don't.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#17895
; Package
emacs
.
(Wed, 02 Jul 2014 21:51:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 17895 <at> debbugs.gnu.org (full text, mbox):
On Wed Jul 2 2014 Glenn Morris wrote:
> Do you have any concrete suggestions for changing Emacs's
> fortran-mode in light of this report?
For me, in fortran-mode the electric-indent-mode moves point
too fast too far ahead. I find this beavior distracting in
fortran-mode. (Yes, the fortran codes I work with do have a good
percentage of comment lines plus some continuation lines.) That's
why I suggested that electric-indent-chars should be locally bound
to nil in fortran-mode.
If that's not acceptable to you as default behavior, I have right
now nothing else to suggest. I guess I'll set up the local binding
in my .emacs. Not a big deal.
We'll see whether anybody else might find the current behavior an
issue.
Roland
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#17895
; Package
emacs
.
(Thu, 03 Jul 2014 02:01:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 17895 <at> debbugs.gnu.org (full text, mbox):
> For me, in fortran-mode the electric-indent-mode moves point
> too fast too far ahead. I find this beavior distracting in
> fortran-mode. (Yes, the fortran codes I work with do have a good
> percentage of comment lines plus some continuation lines.) That's
> why I suggested that electric-indent-chars should be locally bound
> to nil in fortran-mode.
You can also (electric-indent-local-mode -1) from the fortran-mode-hook.
Stefan
Added tag(s) wontfix.
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Tue, 12 Aug 2014 05:48:01 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
17895 <at> debbugs.gnu.org and "Roland Winkler" <winkler <at> gnu.org>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Fri, 04 Mar 2016 15:35:07 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 02 Apr 2016 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 9 years and 81 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.