GNU bug report logs - #33208
26.1; mark-defun gives incorrect results in some fixed format FORTRAN

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 33208 in the body.
You can then email your comments to 33208 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Fairey, Robin M." <Robin.Fairey <at> iti-global.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 26.1; mark-defun gives incorrect results in some fixed format FORTRAN
Date: Tue, 30 Oct 2018 17:11:14 +0000

Starting from emacs -Q,
- Open a new fixed format fortran file ( C-x C-f t e s t . f o r <RET> )
- Populate it with the following text:
      SUBROUTINE ONE

      END SUBROUTINE
C------------------------------------------------------------------------
      SUBROUTINE TWO

      END SUBROUTINE
C------------------------------------------------------------------------
      SUBROUTINE THREE

      END SUBROUTINE

Position point on line 6 (the blank line in TWO), and observe that
M-x mark-defun marks TWO and THREE instead of just TWO.

Inserting an additional newline between the comment line and the start
of TWO results in correct behaviour.

In GNU Emacs 26.1 (build 1, x86_64-w64-mingw32)
 of 2018-05-30 built on CIRROCUMULUS
Repository revision: 07f8f9bc5a51f5aa94eb099f3e15fbe0c20ea1ea
Windowing system distributor 'Microsoft Corp.', version 10.0.17134

Configured using:
 'configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS THREADS LCMS2

Important settings:
  value of $LANG: ENG
  locale-coding-system: cp1252

Major mode: Fortran

Minor modes in effect:
  which-function-mode: t
  show-paren-mode: t
  delete-selection-mode: t
  cua-mode: t
  global-eldoc-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv dired dired-loaddefs format-spec rfc822 mml
mml-sec password-cache epa derived epg epg-config gnus-util rmail
rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils fortran cus-edit easymenu wid-edit
elec-pair which-func imenu paren linum cus-start cus-load easy-mmode
delsel cua-base edmacro kmacro cl-loaddefs cl-lib compile comint
ansi-color ring time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table
term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote w32notify w32 lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 130339 12789)
 (symbols 56 23060 1)
 (miscs 48 54 129)
 (strings 32 36988 1359)
 (string-bytes 1 987122)
 (vectors 16 16244)
 (vector-slots 8 507996 7504)
 (floats 8 65 211)
 (intervals 56 396 0)
 (buffers 992 14))



CONFIDENTIALITY NOTICE: This email message and any attachments to it, is intended only for the individual or entity to which it is addressed and may contain confidential material. If you are not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, please do not disclose, copy, forward, or retain. If you have received this in error, please contact the sender by reply email, erase the original message from your computer system, and destroy all copies of the original message.   Thank You.

Message #8 received at 33208 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Fairey, Robin M." <Robin.Fairey <at> iti-global.com>
Cc: 33208 <at> debbugs.gnu.org
Subject: Re: bug#33208: 26.1; mark-defun gives incorrect results in some
 fixed format FORTRAN
Date: Wed, 09 Dec 2020 17:37:24 +0100

"Fairey, Robin M." <Robin.Fairey <at> iti-global.com> writes:

> Starting from emacs -Q,
> - Open a new fixed format fortran file ( C-x C-f t e s t . f o r <RET> )
> - Populate it with the following text:
>       SUBROUTINE ONE
>
>       END SUBROUTINE
> C------------------------------------------------------------------------
>       SUBROUTINE TWO
>
>       END SUBROUTINE
> C------------------------------------------------------------------------
>       SUBROUTINE THREE
>
>       END SUBROUTINE
>
> Position point on line 6 (the blank line in TWO), and observe that
> M-x mark-defun marks TWO and THREE instead of just TWO.
>
> Inserting an additional newline between the comment line and the start
> of TWO results in correct behaviour.

Looks like the interface of beginning-of-defun-function has changed --
it now takes an optional arg, and fortran-beginning-of-subprogram didn't
implement that.

I've now fixed that in Emacs 28, and mark-defun now seems to work fine
for me there.  (I don't know Fortran, so my testing is limited, though.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #15 received at 33208 <at> debbugs.gnu.org (full text, mbox):

From: Tomas Nordin <tomasn <at> posteo.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, "Fairey, Robin M."
 <Robin.Fairey <at> iti-global.com>
Cc: 33208 <at> debbugs.gnu.org
Subject: Re: bug#33208: 26.1; mark-defun gives incorrect results in some
 fixed format FORTRAN
Date: Thu, 10 Dec 2020 22:01:11 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> "Fairey, Robin M." <Robin.Fairey <at> iti-global.com> writes:
>
>> Starting from emacs -Q,
>> - Open a new fixed format fortran file ( C-x C-f t e s t . f o r <RET> )
>> - Populate it with the following text:
>>       SUBROUTINE ONE
>>
>>       END SUBROUTINE
>> C------------------------------------------------------------------------
>>       SUBROUTINE TWO
>>
>>       END SUBROUTINE
>> C------------------------------------------------------------------------
>>       SUBROUTINE THREE
>>
>>       END SUBROUTINE
>>
>> Position point on line 6 (the blank line in TWO), and observe that
>> M-x mark-defun marks TWO and THREE instead of just TWO.
>>
>> Inserting an additional newline between the comment line and the start
>> of TWO results in correct behaviour.
>
> Looks like the interface of beginning-of-defun-function has changed --
> it now takes an optional arg, and fortran-beginning-of-subprogram didn't
> implement that.
>
> I've now fixed that in Emacs 28, and mark-defun now seems to work fine
> for me there.  (I don't know Fortran, so my testing is limited, though.)

But does fortran-beginning-of-subprogram do what it documents now after
the fix when arg < 0?

I cannot recall ever writing anything in Fortran so I should just keep
silent, but I spent much time recently studying the beginning-of-defun
and friends, so this caught my eye.

Best regards
--
Tomas

Message #18 received at 33208 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Tomas Nordin <tomasn <at> posteo.net>
Cc: "Fairey, Robin M." <Robin.Fairey <at> iti-global.com>, 33208 <at> debbugs.gnu.org
Subject: Re: bug#33208: 26.1; mark-defun gives incorrect results in some
 fixed format FORTRAN
Date: Fri, 11 Dec 2020 16:18:39 +0100

Tomas Nordin <tomasn <at> posteo.net> writes:

> But does fortran-beginning-of-subprogram do what it documents now after
> the fix when arg < 0?

No, it was badly phrased -- it only affects what's the current
subprogram if we're between subprograms.  I've now made the doc string
more accurate.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #21 received at 33208 <at> debbugs.gnu.org (full text, mbox):

From: Tomas Nordin <tomasn <at> posteo.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "Fairey, Robin M." <Robin.Fairey <at> iti-global.com>, 33208 <at> debbugs.gnu.org
Subject: Re: bug#33208: 26.1; mark-defun gives incorrect results in some
 fixed format FORTRAN
Date: Fri, 11 Dec 2020 19:50:31 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Tomas Nordin <tomasn <at> posteo.net> writes:
>
>> But does fortran-beginning-of-subprogram do what it documents now after
>> the fix when arg < 0?
>
> No, it was badly phrased -- it only affects what's the current
> subprogram if we're between subprograms.  I've now made the doc string
> more accurate.

Nice (for the Fortran hackers :)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.