all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: "Harald Jörg" <haj@posteo.de>
Cc: Corwin Brust <corwin@bru.st>,
	66050@debbugs.gnu.org, Mauro Aranda <maurooaranda@gmail.com>,
	rms@gnu.org, Stefan Kangas <stefankangas@gmail.com>
Subject: bug#66050: Making perl-mode.el obsolete
Date: Sun, 24 Sep 2023 18:54:11 -0400	[thread overview]
Message-ID: <jwv7cofb3bn.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87jzsfw6t8.fsf@oook.m.uunet.de> ("Harald Jörg"'s message of "Sun, 24 Sep 2023 22:21:55 +0000")

>> 1. If I have something like:
>> my $some_code = "";
>> $some_code.= q(
>> my $counter = 0;
>> );
>>
>> If I put point at column 0 of the line "my $counter", and hit TAB, I get
>> indentation in perl-mode.  I don't in cperl-mode.  I tried to look into
>> options for making this work but I couldn't find anything.
>
> I consider the behavior of perl-mode to be a bug.

The behavior looks right to me, tho I haven't checked the code if it's
by accident (i.e. because of a bug in `perl-mode`) or not.

> Whatever is within the parens of  q(...) is a string, and will be
> assigned to the variable $some_code.  By "indenting", perl-mode changes
> the value of $some_code by adding spaces.  In my opinion, indenting
> should change the optical layout, but not the code!

Agreed in the sense that `indent-according-to-mode` (and
`indent-region`) should not touch this line.
But TAB should, using this part of `indent-line-function`:

    indent-line-function is a variable defined in ‘indent.el’.
    [...]
    If it is called somewhere where it cannot auto-indent, the function
    should return ‘noindent’ to signal that it didn’t.
    [...]

> The message is technically correct, and generally I consider the ability
> of cperl-mode to locate syntax errors useful.  But I understand that it
> can be annoying while you're typing (I myself don't see these messages
> because I use paredit-mode, but I understand that not everyone wants
> this electricity).  I guess that a way to optionally suppress these
> messages can be found.

I think the way we usually solve these tensions is to replace those
error messages with some kind of highlighting (and if necessary
`help-echo` properties to help the user figure out what this
highlighting is for).

E.g. in ELisp mode, a non-terminated string results in a string-highlight
that bleeds into the subsequent code.  And an argument wrongly placed on
the same line as something already indented within a subexpression as
in:

      (foo arg1
           (some sub
                 expression) badarg2)

gets a `font-lock-warning-face` together with a `help-echo`.


        Stefan






  parent reply	other threads:[~2023-09-24 22:54 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-17 12:47 bug#66050: Making perl-mode.el obsolete Stefan Kangas
2023-09-17 16:34 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-17 18:20   ` Stefan Kangas
2023-09-17 20:59     ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-22  7:39       ` Stefan Kangas
2023-09-24  0:02       ` Harald Jörg
2023-09-24 15:58         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-24 21:29           ` Harald Jörg
2023-09-24 22:12             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-25  9:18               ` Harald Jörg
2023-09-25 10:09                 ` Mauro Aranda
2023-09-25 10:34                   ` Harald Jörg
2023-09-18 14:11 ` Corwin Brust
2023-09-20 18:34   ` Richard Stallman
2023-09-20 23:26     ` Stefan Kangas
2023-09-21  0:08       ` Corwin Brust
2023-09-21  0:16         ` Stefan Kangas
2023-09-21  0:37           ` Corwin Brust
2023-09-21  0:49             ` Stefan Kangas
2023-09-21 14:13           ` Mauro Aranda
2023-09-21 14:20             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-21 20:14               ` Mauro Aranda
2023-09-24  5:30                 ` Stefan Kangas
2023-09-24 22:21             ` Harald Jörg
2023-09-24 22:40               ` Mauro Aranda
2023-09-25  8:33                 ` Harald Jörg
2023-09-25 13:04                   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-24 22:54               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2023-09-25  8:40                 ` Harald Jörg
2023-09-18 16:14 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-24  0:44   ` Harald Jörg
2023-09-24  7:31     ` Stefan Kangas
2023-09-24 16:01       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-26  9:02       ` Richard Stallman
2023-09-23 22:13 ` Harald Jörg
2023-09-24 10:41   ` Stefan Kangas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwv7cofb3bn.fsf-monnier+emacs@gnu.org \
    --to=bug-gnu-emacs@gnu.org \
    --cc=66050@debbugs.gnu.org \
    --cc=corwin@bru.st \
    --cc=haj@posteo.de \
    --cc=maurooaranda@gmail.com \
    --cc=monnier@iro.umontreal.ca \
    --cc=rms@gnu.org \
    --cc=stefankangas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.