unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: rms@gnu.org
Cc: rgm@gnu.org, johnw@gnu.org, 22564@debbugs.gnu.org,
	monnier@iro.umontreal.ca, acm@muc.de, larsi@gnus.org
Subject: bug#22564: Fundamental mode isn't fundamental enough.
Date: Thu, 05 May 2022 08:43:21 +0300	[thread overview]
Message-ID: <83k0b0356u.fsf@gnu.org> (raw)
In-Reply-To: <E1nmNo3-0007Kw-Du@fencepost.gnu.org> (message from Richard Stallman on Wed, 04 May 2022 18:49:15 -0400)

> From: Richard Stallman <rms@gnu.org>
> Cc: rgm@gnu.org, johnw@gnu.org, 22564@debbugs.gnu.org,
> 	monnier@iro.umontreal.ca, acm@muc.de, larsi@gnus.org
> Date: Wed, 04 May 2022 18:49:15 -0400
> 
>   > That is only important to document if enough important major modes
>   > don't customize it.
> 
> Fundamental mode is one -- and that's enough.  It is the default
> mode if you visit a file whose name has no special extension.
> For instance, `foo'.

I disagree with it being important, as I already said.  But I don't
think this aspect is important enough to keep arguing about it, see
below.

> What DOES Electric Indent mode do in Fundamental mode?
> Nothing?
> 
> I am starting to think that is what it does.

No, it isn't "nothing".  Once again, I already gave an example of what
it does in Fundamental.  Here is that example repeated:

  As a simple example, try this in fundamental mode, on an empty line:

    C-u 10 SPC C-u 10 x RET

>   > Sorry, I disagree that Fundamental mode is important.  Its being the
>   > default doesn't mean users frequently see it, not at all.
> 
> I do.  And not for any special reason.  If I want to put some notes
> in a file, I give it a simple name.  I don't add an extension just to
> get some other mode.  (Do you?)  I find that Fundamental mode is fine.

I don't add extensions, but files edited in Emacs frequently do have
extensions and usually have some major mode that is not Fundamental.

So I don't think your use pattern is common.

Nevertheless, if we describe better what the newline and similar
characters do in electric-indent-mode, that would cover Fundamental as
well, no need to do something special about Fundamental, nor to argue
about its importance.

>     > The electric characters normally include the newline, but can also
>     > include other characters as needed by the major mode; see
>     > `electric-indent-chars' for the actual list.
> 
> Adding that would be useful, but it isn't enough because it doesn't
> answer that crucial question.

Which question was that?

>   > > How about adding, "Typically the major mode controls what reindenting does."?
> 
>   > I'm sorry, I don't think I understand how saying that would help.
>   > Unless a person knows "what reindenting does" (or even what is
>   > "reindenting"), this leaves the issue as obscure as it was before.
> 
> The Emacs Manual does not define "reindenting".  It is not exactly
> synonymous with "indenting", so I think this needs clarification 
> in the manual itself.
> 
> Then the doc string of Electric Indent mode could refer to the
> appropriate node in the Emacs Manual.
> 
> I think reindenting means this:
> 
>   In major modes where indenting a line idempotently adjusts its
>   indentation to what is called for by the line's contents and
>   context, "reindenting" the line is the same as indenting it.
> 
>   In other situations, the concept of "reindenting" is not
>   really applicable, so commands that should "reindent" actually
>   do nothing or have some other definion.
> 
> Is this entirely correct?

I don't know.  But I think it is better to say that this mode
automatically indents the current line according to the context (the
surrounding lines) and the rules of the major mode.  After all, the
mode's name is "Electric Indent mode", not "Electric Reindent mode".





  reply	other threads:[~2022-05-05  5:43 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-05 12:55 bug#22564: Fundamental mode isn't fundamental enough Alan Mackenzie
2016-02-05 14:46 ` Eli Zaretskii
2016-02-05 15:13   ` Alan Mackenzie
2016-02-05 15:34     ` Mark Oteiza
2016-02-05 15:38       ` Drew Adams
2016-02-05 17:57         ` Marcin Borkowski
2016-02-05 19:59           ` Drew Adams
2016-02-05 19:26     ` Eli Zaretskii
2016-02-05 20:18       ` Marcin Borkowski
2016-02-06 19:48     ` Richard Stallman
2016-02-05 20:23 ` Glenn Morris
2016-02-05 21:43   ` Glenn Morris
2016-02-05 21:53   ` Alan Mackenzie
2016-02-17  2:50     ` John Wiegley
2022-04-27 14:39       ` Lars Ingebrigtsen
2022-05-01  1:53         ` Richard Stallman
2022-05-01  6:16           ` Eli Zaretskii
2022-05-02 23:47             ` Richard Stallman
2022-05-03  7:03               ` Andreas Röhler
2022-05-03 14:28                 ` Drew Adams
2022-05-03 17:00               ` Eli Zaretskii
2022-05-04 22:49                 ` Richard Stallman
2022-05-05  5:43                   ` Eli Zaretskii [this message]
2022-05-05 11:02                     ` Andreas Röhler
2022-05-05 16:17                       ` Eli Zaretskii
2022-05-05 18:34                         ` Andreas Röhler
2022-05-06 23:20                     ` Richard Stallman
2022-05-07  6:30                       ` Eli Zaretskii
2022-05-07 23:08                         ` Richard Stallman
     [not found] ` <mailman.3748.1454702408.843.bug-gnu-emacs@gnu.org>
2016-02-06 11:06   ` Alan Mackenzie
2016-02-07 18:33     ` Richard Stallman
     [not found] ` <mailman.3712.1454686507.843.bug-gnu-emacs@gnu.org>
2016-02-06 11:21   ` Alan Mackenzie
2016-02-06 14:36     ` Mark Oteiza
2016-02-06 16:59 ` Achim Gratz
2016-02-07 19:09   ` Eli Zaretskii
2016-02-07 21:02 ` Achim Gratz
2016-02-07 21:08   ` Eli Zaretskii
2016-02-08 19:39 ` Achim Gratz
2016-02-08 20:05   ` Eli Zaretskii
2016-02-08 20:18 ` Achim Gratz
2016-02-08 20:53   ` Eli Zaretskii
2016-02-08 21:01 ` Achim Gratz
2016-02-09  3:31   ` Eli Zaretskii
     [not found] <<20160205125559.GC7727@acm.fritz.box>
     [not found] ` <<834mdnusem.fsf@gnu.org>
2016-02-05 15:36   ` Drew Adams
     [not found] <<mailman.3748.1454702408.843.bug-gnu-emacs@gnu.org>
     [not found] ` <<20160206110601.6095.qmail@mail.muc.de>
2016-02-06 15:57   ` Drew Adams
     [not found]   ` <<E1aSU9T-0002aS-5O@fencepost.gnu.org>
2016-02-07 19:43     ` Drew Adams

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=83k0b0356u.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=22564@debbugs.gnu.org \
    --cc=acm@muc.de \
    --cc=johnw@gnu.org \
    --cc=larsi@gnus.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=rgm@gnu.org \
    --cc=rms@gnu.org \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).