From: "Harald Jörg" <haj@posteo.de>
To: Mauro Aranda <maurooaranda@gmail.com>
Cc: Corwin Brust <corwin@bru.st>,
66050@debbugs.gnu.org, Stefan Kangas <stefankangas@gmail.com>,
rms@gnu.org, monnier@iro.umontreal.ca
Subject: bug#66050: Making perl-mode.el obsolete
Date: Mon, 25 Sep 2023 08:33:02 +0000 [thread overview]
Message-ID: <87ttrir6td.fsf@oook.m.uunet.de> (raw)
In-Reply-To: <9915f301-1808-8548-df5e-040e3c028714@gmail.com> (Mauro Aranda's message of "Sun, 24 Sep 2023 19:40:10 -0300")
Mauro Aranda <maurooaranda@gmail.com> writes:
> On 24/9/23 19:21, Harald Jörg wrote:
>> Mauro Aranda <maurooaranda@gmail.com> writes:
>>
>>> In addition to what Jens Schmidt said, I can add that:
>>>
>>> 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.
>>
>> 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!
>
> I might be completely wrong about this, but I have the feeling that
> TAB behaves differently because in perl-mode I see TAB is bound to
> indent-for-tab-command (this is not in emacs -Q, just in case it has
> something to do with that).
>
> So, TAB is not really indenting (as I said originally, sorry), but
> adding a TAB character upon request. And yes, in this case I want to
> change the code, so TAB is not doing anything incorrect here, I think.
I apologize! I made a mistake here: I am so addicted to
cperl-tab-always-indent (t by default) that it didn't occur to me to
even *try* to insert a tab character!
And indeed, cperl-mode does not insert a tab character. Even if
cperl-tab-always-indent is nil, it doesn't insert a character if point
is in the left margin. This is documented in the docstring of
cperl-indent-command.
This behavior of cperl-mode is weird and it makes sense to find a way to
make <tab> insert a tab character.
(A workaround is <C-q> <tab>, but that isn't convincing)
>>> 2. While I'm typing the above string, I get messages about string/RE not
>>> found:
>>> End of ‘q( ... )’ string/RE not found: (scan-error Unbalanced
>>> parentheses 1092 1874)
>>> End of ‘q( ... )’ string/RE not found: (scan-error Unbalanced
>>> parentheses 1092 1918) [2 times]
>>> End of ‘q( ... )’ string/RE not found: (scan-error Unbalanced
>>> parentheses 1092 1962) [2 times]
>>>
>>> That's annoying.
>>
>> 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.
>
> Sure is correct, but I'm used to see messages like those when I have
> really screwed up (typically editing an elisp file and making
> forward-sexp fail). Not while I'm typing. To me, it feels better to
> have kind of a visual indication, like when you are entering a string
> and everything fontifies as a string so you are reminded you better
> close it.
I agree.
Stefan Monnier has suggested how this could be handled in his reply, and
I think this would be an improvement to cperl-mode in general
(independent of using it as a replacement for perl-mode).
>>> So far, my settings for getting a perl-mode experience in cperl-mode,
>>> with emacs -Q: (taken from a custom file):
>>> '(cperl-highlight-variables-indiscriminately t)
>>> '(cperl-indent-level 4)
>>> '(cperl-indent-parens-as-block t)
>>> '(cperl-invalid-face 'default)
>> ,>
>>> '(cperl-array-face ((t (:inherit cperl-hash-face))))
>>> '(cperl-hash-face ((t (:underline t :inherit
>>> font-lock-variable-name-face))))
>>> '(cperl-nonoverridable-face ((t (:inherit default))))
>>
>> Thanks for collecting this!
>
> You're welcome. I'm still trying to figure out if there are more
> settings to tweak. Together with the settings that need to be added for
> a smooth perl-mode -> cperl-mode transition, they could be placed in a
> cperl-perl-mode-users-asylum-theme ;-)
Yes, a custom theme seems to be the way to go.
--
Cheers,
haj
next prev parent reply other threads:[~2023-09-25 8:33 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 [this message]
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
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=87ttrir6td.fsf@oook.m.uunet.de \
--to=haj@posteo.de \
--cc=66050@debbugs.gnu.org \
--cc=corwin@bru.st \
--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.