bug#22564: Fundamental mode isn't fundamental enough.

bug#22564: Fundamental mode isn't fundamental enough.

[Drew Adams]

> >> +1.  Fundamental mode should be Notepad-like as much as possible IMHO.
> >> (Incidentally, I almost never use Fundamental mode, exactly because of
> >> that.)
> 
> > Fundamental mode is not really supposed to be used by users
> > interactively, AFAIK.  It should not even have the functionality
> > of Notepad.  It is used as an empty inheritance point for other
> > modes.  It is the "bottom" of modes. ;-)
> 
> I think fundamental mode existed long before derived modes did.  To say
> it shouldn't be used directly by users is a bit strange, IMAO.  I use it
> fairly often, e.g. when I'm testing, and I want to clear out buffer local
> variables from some buffer, or to re-initialise font locking, or
> something like that.

In that case, I'd still suggest that Fundamental mode should be truly
trivial, with no particular expectation that it be used interactively,
and with it not chosen as the default mode for any buffers in `emacs -Q'.

But I'd also suggest that we create an intermediate mode that is _almost_
trivial, that inherits from Fundamental mode, and that provides whatever
is considered a bare minimum for interactive use.  If that bare minimimum
includes electric indentation, so be it.  But I do think we should not
be adding to Fundamental mode.  (Just one opinion.)

bug#22564: Fundamental mode isn't fundamental enough.

[Drew Adams]

>> I think fundamental mode existed long before derived modes did.
> 
> Fundamental mode has existed since 1984.  The concept of derived modes
> came at least 10 years after that.  What was always true is that other
> major modes obtain their effects by changing some per-buffer values
> away from the defaults that are in effect in Fundamental mode.
							     
>> To say it shouldn't be used directly by users is a bit strange, IMAO.
> 
> It is meant to be used by users.  Creating a buffer puts it in
> Fundamental mode.  Visiting a file which does not specify any mode,
> through its contents or its name, uses Fundamental mode.
> 
> This has always been the case.

Well, yes, but in the past it was really fundamental.  Now it
does fancy "electric" stuff.  That's not bare-bones.

And now we do have derived modes. Fundamental mode is not
only the default default mode for interactive use, it is also
used non-interactively, where things like electric-this-&-that
make little sense (though they may not interfere in some cases).

IMO, if we don't return it to bare-bones interactivity then
we should move the fancy interactive features to a mode
derived from Fundamental mode and leave Fundamental mode
bare-bones - in particular for non-interactive use.

Whether that derived mode should be the new default default
mode is another question.  I don't have a problem if it is,
though that wouldn't be my first choice (I would prefer
bare-bones interactive behavior too.)

IOW, I wouldn't object if the default for interactive use
is electric, but I don't think it's a good idea for fancy
stuff to be added to the "bottom" of the pyramid
(Fundamental mode), which is used also non-interactively.

bug#22564: Fundamental mode isn't fundamental enough.

[Drew Adams]

> > I've just tried to paste some text into a fundamental mode buffer, using
> > GNU/Linux's GPM mouse utility.  It gets fouled up by some facility that
> > decides I want some automatic indentation, despite being in fundamental
> > mode.  As far as I understand, GPM does pasting by effectively typing a
> > character at a time.
> 
> You want to turn off electric-indent-mode, I think.
> 
> > This is surely a bug.
> 
> No, it's a deliberate feature, AFAIU.

In Fundamental mode?  Electric anything in Fundamental mode?

Surely someone was not smoking the right stuff at the time
that was decided.

bug#22564: Fundamental mode isn't fundamental enough.

[Alan Mackenzie]

Hello, Emacs.

I've just tried to paste some text into a fundamental mode buffer, using
GNU/Linux's GPM mouse utility.  It gets fouled up by some facility that
decides I want some automatic indentation, despite being in fundamental
mode.  As far as I understand, GPM does pasting by effectively typing a
character at a time.


The original text (from an email by Michael Duggan) is this:

#########################################################################
In the following C++ snippet:

template <typename Arg, typename... Args>
struct ArgListMatcher<Arg, Args...> :
    ArgListMatcher<MakeIndices<CountRef<Arg>::value>,
                   MakeIndices<sizeof...(Args) - CountRef<Arg>::value, CountRef<Arg>::value>,
                       Arg, Args...>
{
  using Parent = ArgListMatcher<
    MakeIndices<CountRef<Arg>::value>,
    MakeIndices<sizeof...(Args) + 1 - CountRef<Arg>::value,
                CountRef<Arg>::value>, Arg, Args...>;
  using Parent::ArgListMatcher;
};
#########################################################################



The corrupted text, looks like this:

#########################################################################
In the following C++ snippet:

template <typename Arg, typename... Args>
struct ArgListMatcher<Arg, Args...> :
    ArgListMatcher<MakeIndices<CountRef<Arg>::value>,
                       MakeIndices<sizeof...(Args) - CountRef<Arg>::value, CountRef<Arg>::value>,
                                              Arg, Args...>
                                              {
                                                using Parent = ArgListMatcher<
                                                    MakeIndices<CountRef<Arg>::value>,
                                                        MakeIndices<sizeof...(Args) + 1 - CountRef<Arg>::value,
                                                                        CountRef<Arg>::value>, Arg, Args...>;
                                                                          using Parent::ArgListMatcher;
                                                                          };
#########################################################################


Now there will be some sort of option I can set so that this won't
happen.  But I shouldn't have to.  More to the point, a new user who is
unfamiliar with Emacs's documentation shouldn't have to.  Surely the
whole point of fundamental mode is that "clever" things like this should
all be disabled.

This is surely a bug.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#22564: Fundamental mode isn't fundamental enough.

[Eli Zaretskii]

> Date: Fri, 5 Feb 2016 12:55:59 +0000
> From: Alan Mackenzie <acm@muc.de>
> 
> I've just tried to paste some text into a fundamental mode buffer, using
> GNU/Linux's GPM mouse utility.  It gets fouled up by some facility that
> decides I want some automatic indentation, despite being in fundamental
> mode.  As far as I understand, GPM does pasting by effectively typing a
> character at a time.

You want to turn off electric-indent-mode, I think.

> This is surely a bug.

No, it's a deliberate feature, AFAIU.

bug#22564: Fundamental mode isn't fundamental enough.

[Alan Mackenzie]

Hello, Eli.

On Fri, Feb 05, 2016 at 04:46:09PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 5 Feb 2016 12:55:59 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > 
> > I've just tried to paste some text into a fundamental mode buffer, using
> > GNU/Linux's GPM mouse utility.  It gets fouled up by some facility that
> > decides I want some automatic indentation, despite being in fundamental
> > mode.  As far as I understand, GPM does pasting by effectively typing a
> > character at a time.

> You want to turn off electric-indent-mode, I think.

Sort of.  But this is beyond the capabilities of a newby (discovering
that, I mean).

> > This is surely a bug.

> No, it's a deliberate feature, AFAIU.

You mean, there should no longer be a vanilla fundamental mode?  I would
argue that no "helpful" electric modes should be enabled in FM.  At the
moment, it appears, we are lacking a What-You-Do-Is-What-You-Get mode.

I think electric-*-modes should be disabled in FM unless explicitly
enabled by the user in an FM buffer.  We've become far too "clever" with
all these facilities.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#22564: Fundamental mode isn't fundamental enough.

[Mark Oteiza]

Alan Mackenzie <acm@muc.de> writes:
>> No, it's a deliberate feature, AFAIU.
>
> You mean, there should no longer be a vanilla fundamental mode?  I would
> argue that no "helpful" electric modes should be enabled in FM.  At the
> moment, it appears, we are lacking a What-You-Do-Is-What-You-Get mode.
>
> I think electric-*-modes should be disabled in FM unless explicitly
> enabled by the user in an FM buffer.  We've become far too "clever" with
> all these facilities.

electric-indent-mode is the only electric-*-mode on by default, and I
never understood why it was enabled. Up until bracketed paste was
implemented, this issue of indenting pastes had been an annoyance (only
later on did I realize to disable this electric mode).

bug#22564: Fundamental mode isn't fundamental enough.

[Drew Adams]

> > You mean, there should no longer be a vanilla fundamental mode?  I would
> > argue that no "helpful" electric modes should be enabled in FM.  At the
> > moment, it appears, we are lacking a What-You-Do-Is-What-You-Get mode.
> >
> > I think electric-*-modes should be disabled in FM unless explicitly
> > enabled by the user in an FM buffer.  We've become far too "clever" with
> > all these facilities.
> 
> electric-indent-mode is the only electric-*-mode on by default, and I
> never understood why it was enabled. Up until bracketed paste was
> implemented, this issue of indenting pastes had been an annoyance (only
> later on did I realize to disable this electric mode).

I agree.  I disabled it as soon as I encountered it, but I disagree
that users should be subjected to it by default.  Especially in
Fundamental mode.

bug#22564: Fundamental mode isn't fundamental enough.

[Marcin Borkowski]

On 2016-02-05, at 16:38, Drew Adams <drew.adams@oracle.com> wrote:

>> > You mean, there should no longer be a vanilla fundamental mode?  I would
>> > argue that no "helpful" electric modes should be enabled in FM.  At the
>> > moment, it appears, we are lacking a What-You-Do-Is-What-You-Get mode.
>> >
>> > I think electric-*-modes should be disabled in FM unless explicitly
>> > enabled by the user in an FM buffer.  We've become far too "clever" with
>> > all these facilities.
>> 
>> electric-indent-mode is the only electric-*-mode on by default, and I
>> never understood why it was enabled. Up until bracketed paste was
>> implemented, this issue of indenting pastes had been an annoyance (only
>> later on did I realize to disable this electric mode).
>
> I agree.  I disabled it as soon as I encountered it, but I disagree
> that users should be subjected to it by default.  Especially in
> Fundamental mode.

+1.  Fundamental mode should be Notepad-like as much as possible IMHO.
(Incidentally, I almost never use Fundamental mode, exactly because of
that.)

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

bug#22564: Fundamental mode isn't fundamental enough.

[Drew Adams]

> >> electric-indent-mode is the only electric-*-mode on by default, and I
> >> never understood why it was enabled. Up until bracketed paste was
> >> implemented, this issue of indenting pastes had been an annoyance (only
> >> later on did I realize to disable this electric mode).
> >
> > I agree.  I disabled it as soon as I encountered it, but I disagree
> > that users should be subjected to it by default.  Especially in
> > Fundamental mode.
> 
> +1.  Fundamental mode should be Notepad-like as much as possible IMHO.
> (Incidentally, I almost never use Fundamental mode, exactly because of
> that.)

Fundamental mode is not really supposed to be used by users
interactively, AFAIK.  It should not even have the functionality
of Notepad.  It is used as an empty inheritance point for other
modes.  It is the "bottom" of modes. ;-)

bug#22564: Fundamental mode isn't fundamental enough.

[Eli Zaretskii]

> Date: Fri, 5 Feb 2016 15:13:27 +0000
> Cc: 22564@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > You want to turn off electric-indent-mode, I think.
> 
> Sort of.  But this is beyond the capabilities of a newby (discovering
> that, I mean).

If they cannot, they will ask.

> > > This is surely a bug.
> 
> > No, it's a deliberate feature, AFAIU.
> 
> You mean, there should no longer be a vanilla fundamental mode?

We still have Fundamental mode.  But AFAIR no one has ever promised
that Fundamental mode will not have any features turned on by
default.  I think you are misinterpreting what Fundamental means.

Maybe we need a new mode for that, something we never had before.

bug#22564: Fundamental mode isn't fundamental enough.

[Marcin Borkowski]

On 2016-02-05, at 20:26, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Alan Mackenzie <acm@muc.de>
>> 
>> > You want to turn off electric-indent-mode, I think.
>> 
>> Sort of.  But this is beyond the capabilities of a newby (discovering
>> that, I mean).
>
> If they cannot, they will ask.

Or walk away angrily to their Notepads, Notepads++, Sublime Texts etc.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

bug#22564: Fundamental mode isn't fundamental enough.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I think electric-*-modes should be disabled in FM unless explicitly
  > enabled by the user in an FM buffer.  We've become far too "clever" with
  > all these facilities.

I agree.

The doc string of electric-indent-mode says

    When enabled, this reindents whenever the hook ‘electric-indent-functions’
    returns non-nil, or if you insert a character from ‘electric-indent-chars’.

electric-indent-chars is supposed to contain printing characters
whose insertion should, secondarily, cause reindentation of the line.
Why is  tab  in that list?  That makes no sense.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

bug#22564: Fundamental mode isn't fundamental enough.

[Glenn Morris]

Still fighting the electric-indent fight I see.

Purely as a data point, from the Emacs manual:

   The least specialized major mode is called "Fundamental mode".  This
   mode has no mode-specific redefinitions or variable settings, so that
   each Emacs command behaves in its most general manner, and each user
   option variable is in its default state.

It would therefore be against the spirit of fundamental mode to
introduce any mode-specific behaviour for it.

bug#22564: Fundamental mode isn't fundamental enough.

[Glenn Morris]

Anyway, it seems to me that this is nothing to do with any particular
major mode. You can see the same issue if, in emacs -nw, you paste with
the mouse multiple long lines of text from some other application into a
text-mode buffer with auto-fill enabled: they get refilled. Seems like
the same basic issue to me, nothing to do with any particular major (or
minor) mode, rather a limitation of copy/paste in text-mode terminals.

And indeed this is a duplicate of http://debbugs.gnu.org/19093 .
For me it is fixed in emacs-25 (sadly the initial report contains no
information as to Emacs version) by bracketed paste support. (I have no
idea if this does, or can, apply to the Linux console. I tried with -nw
in a graphical session.)

So it seems to that this is already as fixed as it's going to get,
and we don't need to worry about re-jigging fundamental-mode.

bug#22564: Fundamental mode isn't fundamental enough.

[Alan Mackenzie]

Hello, Glenn.

On Fri, Feb 05, 2016 at 03:23:57PM -0500, Glenn Morris wrote:

> Still fighting the electric-indent fight I see.

:-)

> Purely as a data point, from the Emacs manual:

>    The least specialized major mode is called "Fundamental mode".  This
>    mode has no mode-specific redefinitions or variable settings, so that
>    each Emacs command behaves in its most general manner, and each user
>    option variable is in its default state.

> It would therefore be against the spirit of fundamental mode to
> introduce any mode-specific behaviour for it.

I'd agree with that last paragraph.

However, fundamental mode has had mode-specific indentation behaviour
thrust upon it.  You'd probably argue legalistically that once some
indentation behaviour has been made a default, it's no longer
mode-specific.  I'd disagree with you.

Following a particular indentation strategy is _not_ "behaving in the
most general manner", which is what I would like to expect from
fundamental mode.  As Eli intimated, we could really do with an
unspecialised, vanilla major mode, though I've no firm idea what we could
call it: plain-mode, or wydiwyg-mode, or something like that.

The logical upshot would be to make the default indentation behaviour no
indentation.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#22564: Fundamental mode isn't fundamental enough.

[John Wiegley]

[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

>>>>> Alan Mackenzie <acm@muc.de> writes:

>> It would therefore be against the spirit of fundamental mode to introduce
>> any mode-specific behaviour for it.

> I'd agree with that last paragraph.

> However, fundamental mode has had mode-specific indentation behaviour thrust
> upon it. You'd probably argue legalistically that once some indentation
> behaviour has been made a default, it's no longer mode-specific. I'd
> disagree with you.

I would rather that fundamental-mode be as non-magical as possible also.
Anything content-aware (like electric indentation) smacks of enriched behavior
over what is fundamental.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

bug#22564: Fundamental mode isn't fundamental enough.

[Lars Ingebrigtsen]

John Wiegley <jwiegley@gmail.com> writes:

> I would rather that fundamental-mode be as non-magical as possible also.
> Anything content-aware (like electric indentation) smacks of enriched behavior
> over what is fundamental.

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

The issue is whether modes like `electric-indent-mode' should be
disabled in fundamental-mode buffers.  But I don't think that disabling
all global minor modes in fundamental-mode will yield a pleasant result,
especially as so many things are now defined as global minor modes.

By default, a fundamental-mode buffer in "emacs -Q" has the following:

Global minor modes enabled: Auto-Encryption Blink-Cursor
Electric-Indent File-Name-Shadow Global-Eldoc Global-Font-Lock
Show-Paren Tooltip Transient-Mark

For instance, we certainly don't want the cursor to not blink in a
fundamental-mode buffer, or not have transient-mark not work.

So I don't think we want to change anything here, and I'm therefore
closing this bug report.

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

bug#22564: Fundamental mode isn't fundamental enough.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

The doc string of `electric-indent-mode' is deficient -- it fails to say
what it will concretely do in an uncustomized Emacs.  All it says is this:

    When enabled, this reindents whenever the hook ‘electric-indent-functions’
    returns non-nil, or if you insert a character from ‘electric-indent-chars’.

To see what that concretely does, you have to look at those variables.
That's asking too much, for a beginner.  This doc string should say
where to find the specifics of what it does in Fundametal mode.

I looked at them and found that `electric-indent-chars' has TAB (10) in it.
However, TAB has a global binding, `indent-for-tab-command'.

What, then, does Electric Indent mode alter in Fundamental mode?  Does
it alter anything?  Was there a concrete motive for proposing to
disable it in Fundamental mode?  We need to help users find out these
things.  Is there a way, other than by reading electric.el?

The doc string also fails to say what, concretely, reindenting does, or even
what controls what reindenting does.  So it needs a lot of improvement.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#22564: Fundamental mode isn't fundamental enough.

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sat, 30 Apr 2022 21:53:03 -0400
> Cc: jwiegley@gmail.com, johnw@gnu.org, 22564@debbugs.gnu.org, acm@muc.de,
>  rgm@gnu.org
> 
> The doc string of `electric-indent-mode' is deficient -- it fails to say
> what it will concretely do in an uncustomized Emacs.  All it says is this:
> 
>     When enabled, this reindents whenever the hook ‘electric-indent-functions’
>     returns non-nil, or if you insert a character from ‘electric-indent-chars’.
> 
> To see what that concretely does, you have to look at those variables.
> That's asking too much, for a beginner.

The difficulty is that the hook and the characters vary significantly
from major mode to major mode.  The latter one, for example, can in
some modes include characters that are very unintuitive, like ':'.

We could say something like

  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.

Would this help?

> This doc string should say where to find the specifics of what it
> does in Fundametal mode.

Why is that important?  Fundamental mode is not supposed to be used
frequently by Emacs users, so why single out that mode, and why
specifically for this minor mode?

> I looked at them and found that `electric-indent-chars' has TAB (10) in it.
> However, TAB has a global binding, `indent-for-tab-command'.

10 is not TAB, it's C-j (newline).

> What, then, does Electric Indent mode alter in Fundamental mode?  Does
> it alter anything?

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

  C-u 10 SPC C-u 10 x C-j

> Was there a concrete motive for proposing to disable it in
> Fundamental mode?

We enabled it by default in every mode (in Emacs 24), so Fundamental
mode is also affected.

I don't remember the motives; perhaps Stefan (CC'ed) does.

> We need to help users find out these
> things.  Is there a way, other than by reading electric.el?

Not really.

> The doc string also fails to say what, concretely, reindenting does, or even
> what controls what reindenting does.  So it needs a lot of improvement.

The problem is that this feature is implemented with so many opaque
hooks and variables which modes can set and override that it's hard to
describe its workings in a way that is both accurate and general
enough to cover all the modes which employ those hooks and those
variables.

The workhorse is electric-indent-post-self-insert-function; please
take a look at what it does and how, and I think any improvement of
the doc string based on what you see there (and the many rabbit holes
down which it will lead you) will be most welcome.

bug#22564: Fundamental mode isn't fundamental enough.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The difficulty is that the hook and the characters vary significantly
  > from major mode to major mode.  The latter one, for example, can in
  > some modes include characters that are very unintuitive, like ':'.

That is true -- I did not speak clearly.  Of course, when a major mode
customizes this, it's the major mode's responsibility to document
how it sets up such indentation.

But what does Electric Indent mode it do in modes that DON'T customize it?
For instance, what does it do in Fundamental mode?  It doesn't say.
I as a user don't know anywhere to look for this.

  > Why is that important?  Fundamental mode is not supposed to be used
  > frequently by Emacs users, so why single out that mode, and why
  > specifically for this minor mode?

Because Fundamental mode is the default for a file with no special
name or contents to specify another major mode.
And because that minor mode is enabled by default.

So a user who visits the file foo.bar gets behavior
which apparently is not documented anywhere.
Not in the doc string of fundamental-mode,
and not in the doc string of electric-indent-mode.
So where should it be?

  > > The doc string also fails to say what, concretely, reindenting does, or even
  > > what controls what reindenting does.  So it needs a lot of improvement.

How about adding, "Typically the major mode controls what reindenting does."?



-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#22564: Fundamental mode isn't fundamental enough.

[Andreas Röhler]

[-- Attachment #1: Type: text/plain, Size: 121 bytes --]

Switching Electric Indent mode on by default was the mistake, which 
creates difficulties and confusion at many places.


[-- Attachment #2: Type: text/html, Size: 337 bytes --]

bug#22564: Fundamental mode isn't fundamental enough.

[Drew Adams]

> Switching Electric Indent mode on by default
> was the mistake, which creates difficulties
> and confusion at many places.

+1.

bug#22564: Fundamental mode isn't fundamental enough.

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: monnier@iro.umontreal.ca, acm@muc.de, larsi@gnus.org,
> 	johnw@gnu.org, 22564@debbugs.gnu.org, rgm@gnu.org
> Date: Mon, 02 May 2022 19:47:41 -0400
> 
>   > The difficulty is that the hook and the characters vary significantly
>   > from major mode to major mode.  The latter one, for example, can in
>   > some modes include characters that are very unintuitive, like ':'.
> 
> That is true -- I did not speak clearly.  Of course, when a major mode
> customizes this, it's the major mode's responsibility to document
> how it sets up such indentation.
> 
> But what does Electric Indent mode it do in modes that DON'T customize it?

That is only important to document if enough important major modes
don't customize it.

However, I suggested to say something along these lines, and you
didn't respond to that part.  My suggestion was to say this:

  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.

> For instance, what does it do in Fundamental mode?  It doesn't say.
> I as a user don't know anywhere to look for this.
> 
>   > Why is that important?  Fundamental mode is not supposed to be used
>   > frequently by Emacs users, so why single out that mode, and why
>   > specifically for this minor mode?
> 
> Because Fundamental mode is the default for a file with no special
> name or contents to specify another major mode.
> And because that minor mode is enabled by default.

Sorry, I disagree that Fundamental mode is important.  Its being the
default doesn't mean users frequently see it, not at all.

>   > > The doc string also fails to say what, concretely, reindenting does, or even
>   > > what controls what reindenting does.  So it needs a lot of improvement.
> 
> 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.

bug#22564: Fundamental mode isn't fundamental enough.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > But what does Electric Indent mode it do in modes that DON'T customize it?

  > 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'.

What DOES Electric Indent mode do in Fundamental mode?
Nothing?

I am starting to think that is what it does.

  > 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.

    > 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.

If someone tells me the answer, I will document it.

  > > 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?


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#22564: Fundamental mode isn't fundamental enough.

[Eli Zaretskii]

> 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".

bug#22564: Fundamental mode isn't fundamental enough.

[Andreas Röhler]

[-- Attachment #1: Type: text/plain, Size: 413 bytes --]


Am 05.05.22 um 07:43 schrieb Eli Zaretskii:
>
> 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".
>
>
>
A fundamental mode should be as fundamental as possible, stripped by all 
fanciness.

[-- Attachment #2: Type: text/html, Size: 802 bytes --]

bug#22564: Fundamental mode isn't fundamental enough.

[Eli Zaretskii]

> Date: Thu, 5 May 2022 13:02:37 +0200
> From: Andreas Röhler <andreas.roehler@easy-emacs.de>
> 
> A fundamental mode should be as fundamental as possible, stripped by all fanciness.

"Fanciness" is in the eyes of the beholder.  It is clear that you
don't like electric-indent-mode, but that doesn't mean your opinion
represents that of the majority.  We decided to turn that mode ON by
default because quite a few people had other expectations.

Fundamental mode is just a mode.  Richard even says that it is an
important mode.  Then it follows that assuming it has no "fanciness"
whatsoever isn't necessarily correct.

bug#22564: Fundamental mode isn't fundamental enough.

[Andreas Röhler]

[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]


Am 05.05.22 um 18:17 schrieb Eli Zaretskii:
>> Date: Thu, 5 May 2022 13:02:37 +0200
>> From: Andreas Röhler<andreas.roehler@easy-emacs.de>
>>
>> A fundamental mode should be as fundamental as possible, stripped by all fanciness.
> "Fanciness" is in the eyes of the beholder.  It is clear that you
> don't like electric-indent-mode,

Hi Eli,

that's not true. In fact, I use electric-indentation all over the day. 
Just don't want it in environments, where it's not appropriate.

It's easier to switch on stuff than looking how to switch things off.

>   but that doesn't mean your opinion
> represents that of the majority.


Majority is no measure for correctness.  Requiring it, would put 
religion at the place of science.


>    We decided to turn that mode ON by
> default because quite a few people had other expectations.
>
> Fundamental mode is just a mode.

That's bad. Need a reliable basement to build upon. Kind of an empty sheet.


>    Richard even says that it is an
> important mode.  Then it follows that assuming it has no "fanciness"
> whatsoever isn't necessarily correct.

[-- Attachment #2: Type: text/html, Size: 2182 bytes --]

bug#22564: Fundamental mode isn't fundamental enough.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

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

    >   C-u 10 SPC C-u 10 x RET

As far as I could see,  it did not change anything.
So I tried again in emacs -Q, and I saw it indented the
following line.

  > Nevertheless, if we describe better what the newline and similar
  > characters do in electric-indent-mode, that would cover Fundamental as
  > well,

If the description of thoe characters' default behavior is concrete enough,
I think it would do the job.

  > 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".

Maybe.  But I do think the term "reindent" needs to be explined
somewhere in the Emacs manual.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#22564: Fundamental mode isn't fundamental enough.

[Eli Zaretskii]

> 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: Fri, 06 May 2022 19:20:54 -0400
> 
>     > As a simple example, try this in fundamental mode, on an empty line:
> 
>     >   C-u 10 SPC C-u 10 x RET
> 
> As far as I could see,  it did not change anything.
> So I tried again in emacs -Q, and I saw it indented the
> following line.

Are you customizing the command bound to RET in your init files?

Indenting the following line is the expected default behavior, yes.

>   > Nevertheless, if we describe better what the newline and similar
>   > characters do in electric-indent-mode, that would cover Fundamental as
>   > well,
> 
> If the description of thoe characters' default behavior is concrete enough,
> I think it would do the job.

All I can offer to say is what I said here:

>   >                    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.

> Maybe.  But I do think the term "reindent" needs to be explined
> somewhere in the Emacs manual.

If all we need to say is that reindent means to remove any indentation
and then indent the line according to context and major mode's rules,
that's simple enough.

bug#22564: Fundamental mode isn't fundamental enough.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > As far as I could see,  it did not change anything.
  > > So I tried again in emacs -Q, and I saw it indented the
  > > following line.

  > Are you customizing the command bound to RET in your init files?

I can't see any sign that it does that, but I guess it does something
pertinent though I can't tell what.

Anyway, the thing to document is the emacs -Q behavior.

  > Indenting the following line is the expected default behavior, yes.

I think the documentation of Electric Indent mode should say that that
is what it does in modes that don't alter the behavior.  That's explicit.
Why not?

  > > Maybe.  But I do think the term "reindent" needs to be explined
  > > somewhere in the Emacs manual.

  > If all we need to say is that reindent means to remove any indentation
  > and then indent the line according to context and major mode's rules,
  > that's simple enough.

I think that's correct.



-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#22564: Fundamental mode isn't fundamental enough.

[Alan Mackenzie]

In article <mailman.3748.1454702408.843.bug-gnu-emacs@gnu.org> you wrote:
>> >> electric-indent-mode is the only electric-*-mode on by default, and I
>> >> never understood why it was enabled. Up until bracketed paste was
>> >> implemented, this issue of indenting pastes had been an annoyance (only
>> >> later on did I realize to disable this electric mode).
>> >
>> > I agree.  I disabled it as soon as I encountered it, but I disagree
>> > that users should be subjected to it by default.  Especially in
>> > Fundamental mode.
>> 
>> +1.  Fundamental mode should be Notepad-like as much as possible IMHO.
>> (Incidentally, I almost never use Fundamental mode, exactly because of
>> that.)

> Fundamental mode is not really supposed to be used by users
> interactively, AFAIK.  It should not even have the functionality
> of Notepad.  It is used as an empty inheritance point for other
> modes.  It is the "bottom" of modes. ;-)

I think fundamental mode existed long before derived modes did.  To say
it shouldn't be used directly by users is a bit strange, IMAO.  I use it
fairly often, e.g. when I'm testing, and I want to clear out buffer local
variables from some buffer, or to re-initialise font locking, or
something like that.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#22564: Fundamental mode isn't fundamental enough.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I think fundamental mode existed long before derived modes did. 

Fundamental mode has existed since 1984.  The concept of derived modes
came at least 10 years after that.  What was always true is that other
major modes obtain their effects by changing some per-buffer values
away from the defaults that are in effect in Fundamental mode.

								     To say
  > it shouldn't be used directly by users is a bit strange, IMAO.

It is meant to be used by users.  Creating a buffer puts it in
Fundamental mode.  Visiting a file which does not specify any mode,
through its contents or its name, uses Fundamental mode.

This has always been the case.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

bug#22564: Fundamental mode isn't fundamental enough.

[Alan Mackenzie]

Hello, Mark.

In article <mailman.3712.1454686507.843.bug-gnu-emacs@gnu.org> you wrote:

> Alan Mackenzie <acm@muc.de> writes:
>>> No, it's a deliberate feature, AFAIU.

>> You mean, there should no longer be a vanilla fundamental mode?  I would
>> argue that no "helpful" electric modes should be enabled in FM.  At the
>> moment, it appears, we are lacking a What-You-Do-Is-What-You-Get mode.

>> I think electric-*-modes should be disabled in FM unless explicitly
>> enabled by the user in an FM buffer.  We've become far too "clever" with
>> all these facilities.

> electric-indent-mode is the only electric-*-mode on by default, and I
> never understood why it was enabled. Up until bracketed paste was
> implemented, this issue of indenting pastes had been an annoyance (only
> later on did I realize to disable this electric mode).

What is "bracketed paste"?  The term appears only in xterm.el, but that
file doesn't say what it is.

I still think it's a bug that a standard OS paste operation doesn't work
out of the box in a non-specialised buffer.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#22564: Fundamental mode isn't fundamental enough.

[Mark Oteiza]

On 06/02/16 at 11:21am, Alan Mackenzie wrote:
> In article <mailman.3712.1454686507.843.bug-gnu-emacs@gnu.org> you wrote:
>
> > Alan Mackenzie <acm@muc.de> writes:
> >>> No, it's a deliberate feature, AFAIU.
>
> >> You mean, there should no longer be a vanilla fundamental mode?  I would
> >> argue that no "helpful" electric modes should be enabled in FM.  At the
> >> moment, it appears, we are lacking a What-You-Do-Is-What-You-Get mode.
>
> >> I think electric-*-modes should be disabled in FM unless explicitly
> >> enabled by the user in an FM buffer.  We've become far too "clever" with
> >> all these facilities.
>
> > electric-indent-mode is the only electric-*-mode on by default, and I
> > never understood why it was enabled. Up until bracketed paste was
> > implemented, this issue of indenting pastes had been an annoyance (only
> > later on did I realize to disable this electric mode).
>
> What is "bracketed paste"?  The term appears only in xterm.el, but that
> file doesn't say what it is.

It's in NEWS as well. Paraphrasing: it means Emacs understands a chunk of
text that is "bracketed" (surrounded) by escape characters as a string
to be inserted, instead of interpreting each character in the pasted
text as actual user input.

bug#22564: Fundamental mode isn't fundamental enough.

[Achim Gratz]

Mark Oteiza writes:
>> What is "bracketed paste"?  The term appears only in xterm.el, but that
>> file doesn't say what it is.
>
> It's in NEWS as well. Paraphrasing: it means Emacs understands a chunk of
> text that is "bracketed" (surrounded) by escape characters as a string
> to be inserted, instead of interpreting each character in the pasted
> text as actual user input.

That entry does absolutely nothing to explain what "bracketed paste
mode" actually is or how it can be used in Emacs.  A cursory search
leads me to believe that this is something that some terminal emulators
optionally can do and is switched off by default even then.  In other
words, it is completely useless if you're not using one of those
terminal emulators that do support it or on those that do and have it
switched off.

The list of instances where bracketed paste mode isn't available
includes the GUI Emacs frame apparently, so it really shouldn't be
peddled as a solution for the mess that electric indent produces in many
modes when you're pasting stuff in (in my case most often via the middle
mouse button).  It works by pre- and post-fixing anything pasted into
the terminal by an escape sequence, so maybe there is a way to emulate
it somehow for GUI frames, but if there is, I can't find an explanation
of how to turn that feature on and off.

Another prominent example where electric indent shouldn't be active by
default is diff-mode, btw.  Even if I would agree to the general default
of having it on -- I don't, because the cleanup it requires when going
wrong is more tedious than what it saves me otherwise -- that should be
reason enough to provide some way of temporarily switching it off for
operations where you already know it won't work.  Since you often
realize too late that it will interfere, it would be even more helpful
if you could have some function that removes any indent that was
electrically added.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

bug#22564: Fundamental mode isn't fundamental enough.

[Eli Zaretskii]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Sat, 06 Feb 2016 17:59:04 +0100
> 
> Mark Oteiza writes:
> >> What is "bracketed paste"?  The term appears only in xterm.el, but that
> >> file doesn't say what it is.
> >
> > It's in NEWS as well. Paraphrasing: it means Emacs understands a chunk of
> > text that is "bracketed" (surrounded) by escape characters as a string
> > to be inserted, instead of interpreting each character in the pasted
> > text as actual user input.
> 
> That entry does absolutely nothing to explain what "bracketed paste
> mode" actually is or how it can be used in Emacs.

I tried to clarify that entry.

> A cursory search leads me to believe that this is something that
> some terminal emulators optionally can do and is switched off by
> default even then.  In other words, it is completely useless if
> you're not using one of those terminal emulators that do support it
> or on those that do and have it switched off.

The mode is always turned off by default; Emacs automatically turns it
on if the terminal supports it.

> The list of instances where bracketed paste mode isn't available
> includes the GUI Emacs frame apparently, so it really shouldn't be
> peddled as a solution for the mess that electric indent produces in many
> modes when you're pasting stuff in (in my case most often via the middle
> mouse button).

Do you see the indentation happen when you paste into a GUI session?
I don't think this happens on GUI frames; in particular, I cannot
reproduce Alan's original report when I paste the text he provided
into a GUI frame.

AFAIK, this problem is specific to pasting into a TTY frame, so the
bracketed paste mode is indeed relevant.

bug#22564: Fundamental mode isn't fundamental enough.

[Achim Gratz]

Eli Zaretskii writes:
>> That entry does absolutely nothing to explain what "bracketed paste
>> mode" actually is or how it can be used in Emacs.
>
> I tried to clarify that entry.

Thank you.

>> A cursory search leads me to believe that this is something that
>> some terminal emulators optionally can do and is switched off by
>> default even then.  In other words, it is completely useless if
>> you're not using one of those terminal emulators that do support it
>> or on those that do and have it switched off.
>
> The mode is always turned off by default; Emacs automatically turns it
> on if the terminal supports it.

OK, then it seems that this doesn't work on mintty.  How to tell for
sure from within Emacs?  How does Emacs determine the capabilities of
the terminal?

> Do you see the indentation happen when you paste into a GUI session?
> I don't think this happens on GUI frames; in particular, I cannot
> reproduce Alan's original report when I paste the text he provided
> into a GUI frame.

I can only try with Emacs 24.5 at the moment and there pasting works
indeed correctly in a GUI frame, but not in mintty.

> AFAIK, this problem is specific to pasting into a TTY frame, so the
> bracketed paste mode is indeed relevant.

Mintty has implemented bracketed paste mode, but Emacs doesn't seem to
recognize and/or use it, then.  Feel free to split this off into another
bug.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

bug#22564: Fundamental mode isn't fundamental enough.

[Eli Zaretskii]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Sun, 07 Feb 2016 22:02:17 +0100
> 
> > The mode is always turned off by default; Emacs automatically turns it
> > on if the terminal supports it.
> 
> OK, then it seems that this doesn't work on mintty.  How to tell for
> sure from within Emacs?  How does Emacs determine the capabilities of
> the terminal?

Emacs cannot determine these capabilities, AFAIK.  We simply send the
enabling command to the terminal; those which don't support it will
ignore it.

> Mintty has implemented bracketed paste mode, but Emacs doesn't seem to
> recognize and/or use it, then.  Feel free to split this off into another
> bug.

Sounds like a different bug, indeed.  What is the init file in
lisp/term/ that gets used for mintty?

bug#22564: Fundamental mode isn't fundamental enough.

[Achim Gratz]

Eli Zaretskii writes:
>> OK, then it seems that this doesn't work on mintty.  How to tell for
>> sure from within Emacs?  How does Emacs determine the capabilities of
>> the terminal?
>
> Emacs cannot determine these capabilities, AFAIK.  We simply send the
> enabling command to the terminal; those which don't support it will
> ignore it.

Hmm.  The terminal doesn't seem to act like it has seen that sequence,
then.

>> Mintty has implemented bracketed paste mode, but Emacs doesn't seem to
>> recognize and/or use it, then.  Feel free to split this off into another
>> bug.
>
> Sounds like a different bug, indeed.  What is the init file in
> lisp/term/ that gets used for mintty?

Mintty either responds with xterm-256colors or screen-256colors,
depending on the context.  Other than that I don't know which init file
gets used or how to find out.

As another data point, konsole in KDE doesn't seem to be in bracketed
paste mode either when using 24.5 (is that supposed to be already
implemented there?  I think not, at least NEWS doesn't mention it).  A
very recent 25.0.90 does have it, but completely messes up the line
endings (it inserts lots of spurious trailing whitespace).  If I remove
the extraneous whitespace, then the paste is actually OK, i.e. doesn't
get indented.  Whether or not the trailing whitespace gets added seems
to depend on where I copy from: copying from the terminal window itself
adds whitespace, copying from an Emacs GUI frame doesn't.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

bug#22564: Fundamental mode isn't fundamental enough.

[Eli Zaretskii]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Mon, 08 Feb 2016 20:39:36 +0100
> 
> >> Mintty has implemented bracketed paste mode, but Emacs doesn't seem to
> >> recognize and/or use it, then.  Feel free to split this off into another
> >> bug.
> >
> > Sounds like a different bug, indeed.  What is the init file in
> > lisp/term/ that gets used for mintty?
> 
> Mintty either responds with xterm-256colors or screen-256colors,
> depending on the context.  Other than that I don't know which init file
> gets used or how to find out.

Then it loads either xterm.el or screen.el (which loads xterm.el).
xterm.el has a function called xterm--init-bracketed-paste-mode, can
you see if it gets called at startup?

> As another data point, konsole in KDE doesn't seem to be in bracketed
> paste mode either when using 24.5 (is that supposed to be already
> implemented there?  I think not, at least NEWS doesn't mention it).

This is new with Emacs 25, so 24.5 shouldn't have it.

> A very recent 25.0.90 does have it, but completely messes up the
> line endings (it inserts lots of spurious trailing whitespace).  If
> I remove the extraneous whitespace, then the paste is actually OK,
> i.e. doesn't get indented.  Whether or not the trailing whitespace
> gets added seems to depend on where I copy from: copying from the
> terminal window itself adds whitespace, copying from an Emacs GUI
> frame doesn't.

The stuff that gets put into the selection is up to the application
that owns the selection, right?

bug#22564: Fundamental mode isn't fundamental enough.

[Achim Gratz]

Eli Zaretskii writes:
> The stuff that gets put into the selection is up to the application
> that owns the selection, right?

That was the same Emacs in this case that I then pasted the text into.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

bug#22564: Fundamental mode isn't fundamental enough.

[Eli Zaretskii]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Mon, 08 Feb 2016 21:18:45 +0100
> 
> Eli Zaretskii writes:
> > The stuff that gets put into the selection is up to the application
> > that owns the selection, right?
> 
> That was the same Emacs in this case that I then pasted the text into.

No, I mean the application from which the text came.

bug#22564: Fundamental mode isn't fundamental enough.

[Achim Gratz]

Eli Zaretskii writes:
>> > The stuff that gets put into the selection is up to the application
>> > that owns the selection, right?
>> 
>> That was the same Emacs in this case that I then pasted the text into.
>
> No, I mean the application from which the text came.

That's what I meant, I was pasting from the same non-GUI Emacs running
in the konsole terminal.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

bug#22564: Fundamental mode isn't fundamental enough.

[Eli Zaretskii]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Mon, 08 Feb 2016 22:01:59 +0100
> 
> Eli Zaretskii writes:
> >> > The stuff that gets put into the selection is up to the application
> >> > that owns the selection, right?
> >> 
> >> That was the same Emacs in this case that I then pasted the text into.
> >
> > No, I mean the application from which the text came.
> 
> That's what I meant, I was pasting from the same non-GUI Emacs running
> in the konsole terminal.

I'm confused.  You said:

>                             Whether or not the trailing whitespace
> gets added seems to depend on where I copy from: copying from the
> terminal window itself adds whitespace, copying from an Emacs GUI
> frame doesn't.

Do you mean that the terminal window in question was a TTY frame in
the same Emacs session as the GUI frame?  If so, copying from the
terminal frame is not copying from Emacs, but from the terminal
emulator that runs in that window, I think, as Emacs cannot access the
X selection from a TTY frame.  The selection owner in the TTY case is
the terminal emulator, not Emacs.