GNU bug report logs - #21922
Indentation of Emacs Lisp list constants is surprising

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 21922 in the body.
You can then email your comments to 21922 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: Clément Pit--Claudel <clement.pitclaudel <at> live.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Indentation of Emacs Lisp list constants is surprising
Date: Sat, 14 Nov 2015 13:29:54 -0500

[Message part 1 (text/plain, inline)]

Hi all,

I'm posting this following a suggestion from Stefan on a discussion on
Emacs' stackexchange site at https://emacs.stackexchange.com/questions/16942/

Emacs' indentation of Emacs Lisp code is really great, except for one thing:

(defconst one-to-ten '(one two three
                           four five six seven
                           eight nine ten))

Is this actually the preferred way to indent this block? As opposed to

(defconst one-to-ten '(one two three
                       four five six seven
                       eight nine ten))

I find it especially confusing when compared to the default for alists:

(defconst one-to-ten '((one . 1) (two . 2) (three . 3)
                       (four . 4) (five . 5) (six . 6) (seven . 7)
                       (eight . 8) (nine . 9) (ten . 10)))

Is there a reason for this behaviour? I could possibly understand it for 
back-quoted lists, as it would yield better indentation for macros, but 
what about lists? On stackexchange, Oleh suggested using  

(setq lisp-indent-function 'common-lisp-indent-function)

Cheers,
Clément.

In GNU Emacs 25.1.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8)
 of 2015-11-14
Repository revision: 02bf89f857e04b8023ce03eadcfa87c82918e957
Windowing system distributor 'The X.Org Foundation', version 11.0.11501000
System Description:	Linux Mint 17.2 Rafaela

Configured using:
 'configure --with-x-toolkit=gtk3'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
  value of $LC_TIME: en_DK.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-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
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message dired format-spec
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns help-mode easymenu cl-loaddefs pcase cl-lib mail-prsvr
mail-utils time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
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 charscript
case-table epa-hook jka-cmpr-hook help simple abbrev 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 dbusbind inotify
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 80441 7581)
 (symbols 48 19255 0)
 (miscs 40 38 110)
 (strings 32 12779 4612)
 (string-bytes 1 365820)
 (vectors 16 10757)
 (vector-slots 8 419611 2876)
 (floats 8 143 70)
 (intervals 56 194 0)
 (buffers 976 11)
 (heap 1024 25940 1037))

[signature.asc (application/pgp-signature, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Clément Pit--Claudel <clement.pitclaudel <at> live.com>
Cc: 21922 <at> debbugs.gnu.org
Subject: Re: bug#21922: Indentation of Emacs Lisp list constants is surprising
Date: Sun, 15 Nov 2015 21:28:53 +0200

> From: Clément Pit--Claudel <clement.pitclaudel <at> live.com>
> Date: Sat, 14 Nov 2015 13:29:54 -0500
> 
> I'm posting this following a suggestion from Stefan on a discussion on
> Emacs' stackexchange site at https://emacs.stackexchange.com/questions/16942/
> 
> Emacs' indentation of Emacs Lisp code is really great, except for one thing:
> 
> (defconst one-to-ten '(one two three
>                            four five six seven
>                            eight nine ten))
> 
> Is this actually the preferred way to indent this block? As opposed to
> 
> (defconst one-to-ten '(one two three
>                        four five six seven
>                        eight nine ten))
> 
> I find it especially confusing when compared to the default for alists:
> 
> (defconst one-to-ten '((one . 1) (two . 2) (three . 3)
>                        (four . 4) (five . 5) (six . 6) (seven . 7)
>                        (eight . 8) (nine . 9) (ten . 10)))
> 

FWIW, Stefan was wrong: Emacs behaved like that since at least
Emacs 22, so recent changes didn't change this in any way.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Clément Pit--Claudel <clement.pitclaudel <at> live.com>,
 21922 <at> debbugs.gnu.org
Subject: Re: bug#21922: Indentation of Emacs Lisp list constants is surprising
Date: Mon, 16 Nov 2015 02:33:16 +0200

Hi Clément,

On 11/14/2015 08:29 PM, Clément Pit--Claudel wrote:

> I'm posting this following a suggestion from Stefan on a discussion on
> Emacs' stackexchange site at https://emacs.stackexchange.com/questions/16942/

See Stefan's comment under your question. I also think it's a bug.

> Is there a reason for this behaviour? I could possibly understand it for
> back-quoted lists, as it would yield better indentation for macros, but
> what about lists?

We'll have to keep back-quoted lists an exception either way, for 
macros, and because of that we'll sometimes mis-indent "value" lists as 
well, because it can be handy to use backquotes for them, too.

That might be the main reason we haven't bothered to fix this yet. But 
someone should look into fixing the straight-quote case at least, and 
propose a patch.

> On stackexchange, Oleh suggested using
>
> (setq lisp-indent-function 'common-lisp-indent-function)

We recommend against this, e.g. because it would cause a lot of 
indentation changes in the Emacs codebase.

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

From: Luis Henriquez-Perez <luishenriquezperez <at> gmail.com>
To: 21922 <at> debbugs.gnu.org
Subject: Patch for fixing the "straight-quote" case
Date: Mon, 23 Sep 2019 23:16:40 -0400

[Message part 1 (text/plain, inline)]

Hi,

In regards to the issue on the indentation of quoted lists, I'd like to
propose a patch.

It would be changing the predicate of this conditional in the function
`calculate-lisp-indent`.

(if
    (= (point) calculate-lisp-indent-last-sexp)
    ;; Containing sexp has nothing before this line
    ;; except the first element.  Indent under that element.
    nil
  ;; Skip the first element, find start of second (the first
  ;; argument of the function call) and indent under.
  (progn (forward-sexp 1)
         (parse-partial-sexp (point)
                             calculate-lisp-indent-last-sexp
                             0 t)))

It would to this:

(or
 (= (point) calculate-lisp-indent-last-sexp)

 (when-let (point (char-before containing-sexp))
   (char-equal point ?'))

 (let ((quoted-p nil)
       (point nil)
       (positions (nreverse (butlast (elt state 9)))))
   (while (and positions (not quoted-p))
     (setq point (pop positions))
     (setq quoted-p
           (or
            (and (char-before point)
                 (char-equal (char-before point) ?'))
            (save-excursion
              (goto-char (1+ point))
              (looking-at-p "quote[\t\n\f\s]+(")))))
   quoted-p))

This code checks if the `containing-sexp` is quoted and if so indents it
normally (under the first element).

It works for forms quoted with the quote abbreviation ie:
'(a b c d
  e f g)

It also works for explicit quoting:
(quote (a b c
            d e))

Additionally it works for nested lists that are quoted.

'((a b c
   d e))

Please let me know what you think.

[Message part 2 (text/html, inline)]

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Luis Henriquez-Perez <luishenriquezperez <at> gmail.com>
Cc: 21922 <at> debbugs.gnu.org
Subject: Re: bug#21922: Patch for fixing the "straight-quote" case
Date: Tue, 08 Oct 2019 23:41:34 -0400

Luis Henriquez-Perez <luishenriquezperez <at> gmail.com> writes:

>  (when-let (point (char-before containing-sexp))
>    (char-equal point ?'))

>             (and (char-before point)
>                  (char-equal (char-before point) ?'))

You can use eq instead of char-equal, and then the extra check for nil
isn't needed.

>             (save-excursion
>               (goto-char (1+ point))
>               (looking-at-p "quote[\t\n\f\s]+(")))))

I would suggest (looking-at-p "[[:whitespace:]\n]*quote\_>") instead,
and maybe move the save-excursion outside of the loop.

Overall, the approach looks reasonable to me.

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

From: Luis Henriquez-Perez <luishenriquezperez <at> gmail.com>
To: 21922 <at> debbugs.gnu.org
Subject: Fwd: Patch for fixing "straigh-quote" case
Date: Tue, 22 Oct 2019 19:40:38 -0400

[Message part 1 (text/plain, inline)]

---------- Forwarded message ---------
From: Luis Henriquez-Perez <luishenriquezperez <at> gmail.com>
Date: Tue, Oct 22, 2019 at 7:38 PM
Subject: Patch for fixing "straigh-quote" case
To: <21922 <at> debbug.org>


I replied to your personal email instead of this thread. I thought maybe my
replies had not been seen (and also that this should be recorded in the
thread). So this is what I had said:

Thanks for your suggestions.

Here's what the relevant sectiion of code would look like.

(if (or
     (= (point) calculate-lisp-indent-last-sexp)

     (eq (char-after (1+ containing-sexp)) ?:)

     (eq (char-before containing-sexp) ?')

     (let ((quoted-p nil)
           (point nil)
           (positions (nreverse (butlast (elt state 9)))))
      (save-excursion
        (while (and positions (not quoted-p))
         (setq point (pop positions))
         (setq quoted-p
          (or (eq (char-before point) ?')
           (goto-char (1+ point))
           (looking-at-p "[[:space:]]*quote\\>")))))
      quoted-p))
    ;; Containing sexp has nothing before this line
    ;; except the first element.  Indent under that element.
    nil
  ;; Skip the first element, find start of second (the first
  ;; argument of the function call) and indent under.
  (progn (forward-sexp 1)
   (parse-partial-sexp (point)
    calculate-lisp-indent-last-sexp
    0 t)))

question 1:
I get an `unknown posix character class` error when I try (looking-at-p
"[[:whitespace:]\n]*quote\_>").  Did you mean to use [[:space:]] instead?
Did you mean:  (looking-at-p "[[:space:]]*quote\\>")?

question 2:
The reason I used explicit whitespace character is because matches for
character classes like [[:space:]] are dependent on the active syntax table
in the buffer (see this issue
<https://emacs.stackexchange.com/questions/40911/why-do-regexp-that-matches-text-in-buffer-does-not-necessarily-match-same-text>).
Not sure if this will be a problem though, what do you think?

[Message part 2 (text/html, inline)]

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Luis Henriquez-Perez <luishenriquezperez <at> gmail.com>
Cc: 21922 <at> debbugs.gnu.org
Subject: Re: bug#21922: Fwd: Patch for fixing "straigh-quote" case
Date: Tue, 22 Oct 2019 19:59:55 -0400

Luis Henriquez-Perez <luishenriquezperez <at> gmail.com> writes:

> I replied to your personal email instead of this thread. I thought maybe my
> replies had not been seen (and also that this should be recorded in the
> thread). So this is what I had said:

I did you see your messages, just haven't had so much time for handling
Emacs bugs recently.  I was going to forward it to the list before
replying, so thanks for doing that.

> question 1:
> I get an `unknown posix character class` error when I try (looking-at-p
> "[[:whitespace:]\n]*quote\_>").  Did you mean to use [[:space:]] instead?
> Did you mean:  (looking-at-p "[[:space:]]*quote\\>")?

I mixed things up a bit, I meant to say

    (looking-at-p "[[:space:]\n]*quote\\_>")

The "\n" is needed because it typically has comment-ender syntax instead
of space syntax.  "\\>" matches end of word, "\\_>" is end of symbol.

> question 2:
> The reason I used explicit whitespace character is because matches for
> character classes like [[:space:]] are dependent on the active syntax table
> in the buffer (see this issue
> <https://emacs.stackexchange.com/questions/40911/why-do-regexp-that-matches-text-in-buffer-does-not-necessarily-match-same-text>).
> Not sure if this will be a problem though, what do you think?

I think relying on the mode's syntax table makes sense, though it
probably doesn't matter a whole lot either way.

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

From: Luis Henriquez-Perez <luishenriquezperez <at> gmail.com>
To: 21922 <at> debbugs.gnu.org
Subject: Fwd: bug#21922: Fwd: Patch for fixing "straigh-quote" case
Date: Tue, 22 Oct 2019 20:42:38 -0400

[Message part 1 (text/plain, inline)]

---------- Forwarded message ---------
From: Luis Henriquez-Perez <luishenriquezperez <at> gmail.com>
Date: Tue, Oct 22, 2019 at 8:41 PM
Subject: Re: bug#21922: Fwd: Patch for fixing "straigh-quote" case
To: Noam Postavsky <npostavs <at> gmail.com>



>> I did see your message.

Ok, take your time. I just wanted to make sure I sent this to the right
place.

>> I meant to say (looking-at-p "[[:space:]\n]*quote\\_>")

I changed "[[:space:]\n]" -> "[[:space:]]\n" because I think that's what
you meant.


I posted the result of these change at the bottom of this reply.

I'm new to contributing patches. Is there anything else I need to do to get
this
into emacs?

```elisp
(if (or
     (= (point) calculate-lisp-indent-last-sexp)

     (eq (char-after (1+ containing-sexp)) ?:)

     (eq (char-before containing-sexp) ?')

     (let ((quoted-p nil)
           (point nil)
           (positions (nreverse (butlast (elt state 9)))))
      (save-excursion
        (while (and positions (not quoted-p))
         (setq point (pop positions))
         (setq quoted-p
          (or (eq (char-before point) ?')
           (goto-char (1+ point))
           (looking-at-p "[[:space:]]\n*quote\\_>")))))
      quoted-p))
    ;; Containing sexp has nothing before this line
    ;; except the first element.  Indent under that element.
    nil
  ;; Skip the first element, find start of second (the first
  ;; argument of the function call) and indent under.
  (progn (forward-sexp 1)
   (parse-partial-sexp (point)
    calculate-lisp-indent-last-sexp
    0 t)))
```

On Tue, Oct 22, 2019 at 7:59 PM Noam Postavsky <npostavs <at> gmail.com> wrote:

> Luis Henriquez-Perez <luishenriquezperez <at> gmail.com> writes:
>
> > I replied to your personal email instead of this thread. I thought maybe
> my
> > replies had not been seen (and also that this should be recorded in the
> > thread). So this is what I had said:
>
> I did you see your messages, just haven't had so much time for handling
> Emacs bugs recently.  I was going to forward it to the list before
> replying, so thanks for doing that.
>
> > question 1:
> > I get an `unknown posix character class` error when I try (looking-at-p
> > "[[:whitespace:]\n]*quote\_>").  Did you mean to use [[:space:]] instead?
> > Did you mean:  (looking-at-p "[[:space:]]*quote\\>")?
>
> I mixed things up a bit, I meant to say
>
>     (looking-at-p "[[:space:]\n]*quote\\_>")
>
> The "\n" is needed because it typically has comment-ender syntax instead
> of space syntax.  "\\>" matches end of word, "\\_>" is end of symbol.
>
> > question 2:
> > The reason I used explicit whitespace character is because matches for
> > character classes like [[:space:]] are dependent on the active syntax
> table
> > in the buffer (see this issue
> > <
> https://emacs.stackexchange.com/questions/40911/why-do-regexp-that-matches-text-in-buffer-does-not-necessarily-match-same-text
> >).
> > Not sure if this will be a problem though, what do you think?
>
> I think relying on the mode's syntax table makes sense, though it
> probably doesn't matter a whole lot either way.
>

[Message part 2 (text/html, inline)]

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Luis Henriquez-Perez <luishenriquezperez <at> gmail.com>
Cc: 21922 <at> debbugs.gnu.org
Subject: Re: bug#21922: Fwd: bug#21922: Fwd: Patch for fixing "straigh-quote"
 case
Date: Tue, 22 Oct 2019 20:55:55 -0400

Luis Henriquez-Perez <luishenriquezperez <at> gmail.com> writes:

>>> I meant to say (looking-at-p "[[:space:]\n]*quote\\_>")
>
> I changed "[[:space:]\n]" -> "[[:space:]]\n" because I think that's what
> you meant.

No, this time I actually managed to write what I meant :)

"[[:space:]\n]*" will match any number of whitespace-syntax or newline
characters, whereas "[[:space:]]\n*" will match exactly one
whitespace-syntax character, followed by any number of newlines.

> I'm new to contributing patches. Is there anything else I need to do
> to get this into emacs?

It would be more convenient to have your change as a patch, rather than
just the resulting code.  If you have the Emacs git repo, committing
locally and attaching the result of 'git format-patch' as described in
CONTRIBUTE would be the best way.  Otherwise, even just the output of

    diff -u lisp/emacs-lisp/lisp-mode.el.original lisp/emacs-lisp/lisp-mode.el

would be helpful.

Oh, and adding a test to test/lisp/emacs-lisp/lisp-mode-tests.el would
be good as well (e.g., to catch mistakes like using "[[:space:]]\n*"
instead of "[[:space:]\n]*").

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

From: Luis Henriquez-Perez <luishenriquezperez <at> gmail.com>
To: 21922 <at> debbugs.gnu.org
Subject: Fwd: bug#21922: Fwd: bug#21922: Fwd: Patch for fixing "straigh-quote"
 case
Date: Tue, 22 Oct 2019 21:28:04 -0400

[Message part 1 (text/plain, inline)]

---------- Forwarded message ---------
From: Luis Henriquez-Perez <luishenriquezperez <at> gmail.com>
Date: Tue, Oct 22, 2019 at 9:27 PM
Subject: Re: bug#21922: Fwd: bug#21922: Fwd: Patch for fixing
"straigh-quote" case
To: Noam Postavsky <npostavs <at> gmail.com>


>> No, this time I ... managed to write what I meant.

Oh ok. I learned something new. I had thought that the whitespace syntax
needed
two pairs of square brackets surrounding it. So I didn't think
"[[:space:]\n]"
was legal. I thought it had to be written as "[[[:space:]]\n]". After
testing it
I see that you're right. What you have is what (rx (any space "\n"))
returns.

>>  It would be more convenient to have your change as a patch

>> ... adding a test ... would be good as well.

Ok I'll set about doing these things and reply to this thread again when
I'm done.

On Tue, Oct 22, 2019 at 8:55 PM Noam Postavsky <npostavs <at> gmail.com> wrote:

> Luis Henriquez-Perez <luishenriquezperez <at> gmail.com> writes:
>
> >>> I meant to say (looking-at-p "[[:space:]\n]*quote\\_>")
> >
> > I changed "[[:space:]\n]" -> "[[:space:]]\n" because I think that's what
> > you meant.
>
> No, this time I actually managed to write what I meant :)
>
> "[[:space:]\n]*" will match any number of whitespace-syntax or newline
> characters, whereas "[[:space:]]\n*" will match exactly one
> whitespace-syntax character, followed by any number of newlines.
>
> > I'm new to contributing patches. Is there anything else I need to do
> > to get this into emacs?
>
> It would be more convenient to have your change as a patch, rather than
> just the resulting code.  If you have the Emacs git repo, committing
> locally and attaching the result of 'git format-patch' as described in
> CONTRIBUTE would be the best way.  Otherwise, even just the output of
>
>     diff -u lisp/emacs-lisp/lisp-mode.el.original
> lisp/emacs-lisp/lisp-mode.el
>
> would be helpful.
>
> Oh, and adding a test to test/lisp/emacs-lisp/lisp-mode-tests.el would
> be good as well (e.g., to catch mistakes like using "[[:space:]]\n*"
> instead of "[[:space:]\n]*").
>

[Message part 2 (text/html, inline)]

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

From: Alexander Shukaev <emacs <at> Alexander.Shukaev.name>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 27646 <at> debbugs.gnu.org, 21922 <at> debbugs.gnu.org
Subject: Re: bug#27646: Bug: Emacs Lisp Indentation
Date: Fri, 17 Jan 2020 21:26:49 +0100

On 17/01/2020 18:58, Noam Postavsky wrote:
> tags 27646 - moreinfo unreproducible
> forcemerge 21922 27646
> quit
> 
> Alexander Shukaev <emacs <at> Alexander.Shukaev.name> writes:
> 
>> to the "*scratch*" buffer and indent to observe the following result
>>
>> (dolist (symbol '(ignore-errors
>>                     xxx
>>                     yyy)))
>>
>> The reason why this happens is because `ignore-errors' is a macro that has
>>
>> (declare (indent defun))
>>
>> Any other macro with the same declaration whose innocent symbol is
>> used as the first element in a list would reproduce the above
>> indentation bug.  Backquote is also affected.
> 
> That's Bug#21922, although the backquoted case is intentional (e.g., for
> writing code in macros).
> 

I use the following trick right now:

(dolist (symbol '(;
                  ignore-errors
                  xxx
                  yyy)))

Since it's impossible to resolve that issue reliably and for all cases 
including backquote, I propose to introduce some special comment (aka 
;###list) format to indicate that this is a list rather than code to be 
evaluated.  In different contexts the same code could be desired to be 
treated differently namely either as data or as to be evaluated.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Alexander Shukaev <emacs <at> Alexander.Shukaev.name>
Cc: 27646 <at> debbugs.gnu.org, Noam Postavsky <npostavs <at> gmail.com>,
 21922 <at> debbugs.gnu.org
Subject: Re: bug#27646: Bug: Emacs Lisp Indentation
Date: Sun, 30 Jan 2022 23:46:45 +0100

Alexander Shukaev <emacs <at> Alexander.Shukaev.name> writes:

> I use the following trick right now:
>
> (dolist (symbol '(;
>                   ignore-errors
>                   xxx
>                   yyy)))
>
> Since it's impossible to resolve that issue reliably and for all cases
> including backquote, I propose to introduce some special comment (aka
> ;###list) format to indicate that this is a list rather than code to
> be evaluated.  In different contexts the same code could be desired to
> be treated differently namely either as data or as to be evaluated.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

This is bee fixed in recent Emacs version by introducing the following
convention:

(dolist (symbol '( ignore-errors
                   xxx
                   yyy)))

That is, a space after the opening parenthesis to signal that it's a
list and not code.

I'm therefore closing this bug report.

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

Previous Next

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