Box cursor at EoL

Box cursor at EoL

[Dr Rainer Woitok]

Greetings,

being in the process of "converting" from XEmacs to Emacs I currently am
missing XEmacs' habbit  of using a  different cursor shape  for a cursor
sitting on an invisible EoL character  as opposed to a cursor sitting on
an as invisible trailing blank.   I always loved  this feature of XEmacs
because I've always hated unnoticed trailing blanks :-)

Searching the web  up to now I only found references  to using different
cursors for  active/inactive frames  or for different major/minor modes.
Because an EoL character is slimmer than a blank,  I tried setting vari-
able "x-stretch-cursor" to t, but as the "-stretch-" part in the name is
already suggesting, this variable has only effect on wider characters.

So I'm now asking the combined wisdom of this list  whether or not there
is a way to coax Emacs into using a different cursor at EoL.

Any pointers welcome :-)

Sincerely,
  Rainer

Re: Box cursor at EoL

[Marcus Harnisch]

Hi Rainer

On 05/10/2022 17.16, Dr Rainer Woitok wrote:
> being in the process of "converting" from XEmacs to Emacs I currently am
> missing XEmacs' habbit  of using a  different cursor shape  for a cursor
> sitting on an invisible EoL character  as opposed to a cursor sitting on
> an as invisible trailing blank.   I always loved  this feature of XEmacs
> because I've always hated unnoticed trailing blanks :-)

Been there, done that. Here's a snippet from my ‘init.el’:

;; Turns out I really missed this from XEmacs
(defvar cursor-type-at-eol '(bar . 5)
   "Cursor shape to use when point moves to end of line.

XEmacs nostalgia, which gives a nice visual cue about trailing
whitespace.

See also `change-cursor-at-end-of-line'.")

(defun change-cursor-at-end-of-line ()
   "Change shape of cursor to value of `cursor-type-at-eol' at end of line.

When the cursor is moved away from end of line, its shape returns
to its default value. This gives a cue about trailing whitespace
that is even less in your face than `whitespace-newline-mode'.

Add this to `post-command-hook' to enable the feature."
   (while-no-input
     (if (eolp)
         (setq cursor-type cursor-type-at-eol)
       (setq cursor-type (default-value 'cursor-type))
       )))

;; Oddly this doesn't seem to always work with Emacs 27.1. Never
;; noticed any problem with 26.3.
(add-hook 'post-command-hook 'change-cursor-at-end-of-line)

Kind regards,
Marcus

Re: Box cursor at EoL

[Eli Zaretskii]

> From: Dr Rainer Woitok <rainer.woitok@gmail.com>
> Date: Wed, 5 Oct 2022 17:16:44 +0200
> 
> being in the process of "converting" from XEmacs to Emacs I currently am
> missing XEmacs' habbit  of using a  different cursor shape  for a cursor
> sitting on an invisible EoL character  as opposed to a cursor sitting on
> an as invisible trailing blank.   I always loved  this feature of XEmacs
> because I've always hated unnoticed trailing blanks :-)

If this is only because you want to see the trailing blanks, then
customize show-trailing-whitespace to a non-nil value, and these
trailing blanks will be shown in distinct color.

Re: Box cursor at EoL

[Emanuel Berg]

Dr Rainer Woitok wrote:

> being in the process of "converting" from XEmacs to Emacs
> I currently am missing XEmacs' habbit of using a different
> cursor shape for a cursor sitting on an invisible EoL
> character as opposed to a cursor sitting on an as invisible
> trailing blank. I always loved this feature of XEmacs
> because I've always hated unnoticed trailing blanks :-)

You can have them always removed on save,

(defun before-save-hook-f ()
  (delete-trailing-whitespace) )
(add-hook 'before-save-hook #'before-save-hook-f)

-- 
underground experts united
https://dataswamp.org/~incal

Re: Box cursor at EoL

[Emanuel Berg]

Eli Zaretskii wrote:

> If this is only because you want to see the trailing blanks,
> then customize show-trailing-whitespace to a non-nil value,
> and these trailing blanks will be shown in distinct color.

It's better to never see them, but always remove them ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: Box cursor at EoL

[Dr Rainer Woitok]

Marcus,

On Wednesday, 2022-10-05 17:34:04 +0200, you wrote:

> ...
> Been there, done that. Here's a snippet from my ‘init.el’:
> 
> ;; Turns out I really missed this from XEmacs
> ...

Thank you for this hook function.  Works like a charm :-)

> ...
> ;; Oddly this doesn't seem to always work with Emacs 27.1. Never
> ;; noticed any problem with 26.3.

I'm on Emacs 28.1 and up to now it didn't yet fail on me.

Sincerely,
  Rainer

PS: Sorry for the duplicate mail, I forgot to "Cc" the list :-/.

Re: Box cursor at EoL

[Dr Rainer Woitok]

Eli,

On Wednesday, 2022-10-05 19:53:03 +0300, you wrote:

> ...
> If this is only because you want to see the trailing blanks, then
> customize show-trailing-whitespace to a non-nil value, and these
> trailing blanks will be shown in distinct color.

That's just another good idea, because it also shows trailing whitespace
in lines other than  the current one.   So I added this  to my "init.el"
together with Marcus' hook function.  Thank you too :-)

Sincerely,
  Rainer

Re: Box cursor at EoL

[Marcus Harnisch]

Hi Rainer

You are welcome :-)

On 06/10/2022 17.53, Dr Rainer Woitok wrote:
> On Wednesday, 2022-10-05 17:34:04 +0200, you wrote:
>> ...
>> ;; Oddly this doesn't seem to always work with Emacs 27.1. Never
>> ;; noticed any problem with 26.3.
> 
> I'm on Emacs 28.1 and up to now it didn't yet fail on me.

IIRC, the problem was that the cursor-update didn't always happen when 
point moved at end of line. It was never bad enough to make me invest 
time in debugging this. Meanwhile I pay less attention, so I can't tell 
of the top of my head whether this changed in 28.1.

Cheers,
Marcus

Re: Box cursor at EoL

[Stefan Monnier via Users list for the GNU Emacs text editor]

> (defun change-cursor-at-end-of-line ()
>   "Change shape of cursor to value of `cursor-type-at-eol' at end of line.
>
> When the cursor is moved away from end of line, its shape returns
> to its default value. This gives a cue about trailing whitespace
> that is even less in your face than `whitespace-newline-mode'.
>
> Add this to `post-command-hook' to enable the feature."
>   (while-no-input
>     (if (eolp)
>         (setq cursor-type cursor-type-at-eol)
>       (setq cursor-type (default-value 'cursor-type))
>       )))

I suspect the `while-no-input` makes no difference here.
And the next three lines can be simplified to:

    (setq cursor-type
          (if (eolp) cursor-type-at-eol (default-value 'cursor-type)))

> ;; Oddly this doesn't seem to always work with Emacs 27.1. Never
> ;; noticed any problem with 26.3.
> (add-hook 'post-command-hook 'change-cursor-at-end-of-line)

Nowadays you could also use the `pre-redisplay-function` hook which
could have some advantages, but in any case the limit of the above
approach is that it can't correctly account for all the cases where the
buffer is displayed in several windows, with some windows' cursor at
EOL and others not :-(


        Stefan

Re: Box cursor at EoL

[Marcus Harnisch]

On 06/10/2022 21.34, Stefan Monnier via Users list for the GNU Emacs 
text editor wrote:
> I suspect the `while-no-input` makes no difference here.
> And the next three lines can be simplified to:
> 
>      (setq cursor-type
>            (if (eolp) cursor-type-at-eol (default-value 'cursor-type)))
> 
>> ;; Oddly this doesn't seem to always work with Emacs 27.1. Never
>> ;; noticed any problem with 26.3.
>> (add-hook 'post-command-hook 'change-cursor-at-end-of-line)
> 
> Nowadays you could also use the `pre-redisplay-function` hook which
> could have some advantages, but in any case the limit of the above
> approach is that it can't correctly account for all the cases where the
> buffer is displayed in several windows, with some windows' cursor at
> EOL and others not :-(

Thank you very much for your advice. I see the issue with same 
buffer/multiple windows but that is a situation that is rarely part of 
my work pattern. When it is, I am usually not worried about trailing 
whitespace at the same time :)

Re: Box cursor at EoL

[Dr Rainer Woitok]

Stefan,

On Thursday, 2022-10-06 15:34:17 -0400, you wrote:

> ...
> Nowadays you could also use the `pre-redisplay-function` hook which
> could have some advantages,

Could you please elaborate somewhat?

>                             but in any case the limit of the above
> approach is that it can't correctly account for all the cases where the
> buffer is displayed in several windows, with some windows' cursor at
> EOL and others not :-(

Well, I'm rarely using windows, normally I would open the same file in a
different frame,  so the question arises:  is there such a  concept as a
FRAME-local variable?

Sincerely,
  Rainer

Re: Box cursor at EoL

[Eli Zaretskii]

> From: Dr Rainer Woitok <rainer.woitok@gmail.com>
> Date: Fri, 7 Oct 2022 10:28:48 +0200
> Cc: help-gnu-emacs@gnu.org
> 
> Well, I'm rarely using windows, normally I would open the same file in a
> different frame,  so the question arises:  is there such a  concept as a
> FRAME-local variable?

Yes: frame parameters can be used to that effect.

Re: Box cursor at EoL

[Robert Pluim]

>>>>> On Fri, 07 Oct 2022 14:11:34 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Dr Rainer Woitok <rainer.woitok@gmail.com>
    >> Date: Fri, 7 Oct 2022 10:28:48 +0200
    >> Cc: help-gnu-emacs@gnu.org
    >> 
    >> Well, I'm rarely using windows, normally I would open the same file in a
    >> different frame,  so the question arises:  is there such a  concept as a
    >> FRAME-local variable?

    Eli> Yes: frame parameters can be used to that effect.

Except you have to do

    (frame-parameter nil 'my-frame-parameter)

to get at the value. Thereʼs no `make-frame-local-variable' to give a
variable a separate value in a frame. Perhaps thatʼs for the best,
looking up a variableʼs value is already complicated enough :-)

Robert
-- 

Re: Box cursor at EoL

[Dr Rainer Woitok]

Eli,

On Friday, 2022-10-07 14:11:34 +0300, you wrote:

> ...
> > Well, I'm rarely using windows, normally I would open the same file in a
> > different frame,  so the question arises:  is there such a  concept as a
> > FRAME-local variable?
> 
> Yes: frame parameters can be used to that effect.

Ok, so I changed my hook function to

   (lambda () (while-no-input
                 (set-frame-parameter nil               ; Current frame.
                                      'cursor-type      ; Variable name.
                                      (if (eolp) EoL-Cursor ; EoL value.
                                                     Cursor ; Nrm value.
   )          )  )                    )

That works in different frames,  but of course not  in different windows
within the same frame.  However replacing function `set-frame-parameter´
with `set-window-parameter´ prevented the hook function  from working at
all, so `cursor-type´ doesn't seem to be a legal window parameter :-(

Can't I use window parameters to store cursor specific information?

Sincerely,
  Rainer

Re: Box cursor at EoL

[Eli Zaretskii]

> From: Dr Rainer Woitok <rainer.woitok@gmail.com>
> Date: Fri, 7 Oct 2022 16:56:52 +0200
> Cc: help-gnu-emacs@gnu.org
> 
> > Yes: frame parameters can be used to that effect.
> 
> Ok, so I changed my hook function to
> 
>    (lambda () (while-no-input
>                  (set-frame-parameter nil               ; Current frame.
>                                       'cursor-type      ; Variable name.
>                                       (if (eolp) EoL-Cursor ; EoL value.
>                                                      Cursor ; Nrm value.
>    )          )  )                    )
> 
> That works in different frames,  but of course not  in different windows
> within the same frame.  However replacing function `set-frame-parameter´
> with `set-window-parameter´ prevented the hook function  from working at
> all, so `cursor-type´ doesn't seem to be a legal window parameter :-(

How do you access cursor-type when it is a window parameter?

Re: Box cursor at EoL

[Dr Rainer Woitok]

Eli,

On Friday, 2022-10-07 18:37:38 +0300, you wrote:

> ...
> >    (lambda () (while-no-input
> >                  (set-frame-parameter nil               ; Current frame.
> >                                       'cursor-type      ; Variable name.
> >                                       (if (eolp) EoL-Cursor ; EoL value.
> >                                                      Cursor ; Nrm value.
> >    )          )  )                    )
> > 
> > That works in different frames,  but of course not  in different windows
> > within the same frame.  However replacing function `set-frame-parameter´
> > with `set-window-parameter´ prevented the hook function  from working at
> > all, so `cursor-type´ doesn't seem to be a legal window parameter :-(
> 
> How do you access cursor-type when it is a window parameter?

Erm, I don't.  Emacs does (at least when I use `setq´ or `set-frame-par-
ameter´).   I just specify which cursor I want to see in which situation
and have Emacs do the rest.

But thinking twice,  my assumption regarding "`cursor-type´ doesn't seem
to be a legal window parameter" might be wrong; it could as well be that
Emacs just doesn't look there  for a cursor specification  and thus uses
the default cursor all the time in that case.

Sincerely,
  Rainer

Re: Box cursor at EoL

[Eli Zaretskii]

> From: Dr Rainer Woitok <rainer.woitok@gmail.com>
> Date: Sat, 8 Oct 2022 11:03:13 +0200
> Cc: help-gnu-emacs@gnu.org
> 
> > >    (lambda () (while-no-input
> > >                  (set-frame-parameter nil               ; Current frame.
> > >                                       'cursor-type      ; Variable name.
> > >                                       (if (eolp) EoL-Cursor ; EoL value.
> > >                                                      Cursor ; Nrm value.
> > >    )          )  )                    )
> > > 
> > > That works in different frames,  but of course not  in different windows
> > > within the same frame.  However replacing function `set-frame-parameter´
> > > with `set-window-parameter´ prevented the hook function  from working at
> > > all, so `cursor-type´ doesn't seem to be a legal window parameter :-(
> > 
> > How do you access cursor-type when it is a window parameter?
> 
> Erm, I don't.  Emacs does (at least when I use `setq´ or `set-frame-par-
> ameter´).   I just specify which cursor I want to see in which situation
> and have Emacs do the rest.
> 
> But thinking twice,  my assumption regarding "`cursor-type´ doesn't seem
> to be a legal window parameter" might be wrong; it could as well be that
> Emacs just doesn't look there  for a cursor specification  and thus uses
> the default cursor all the time in that case.

Yes, you must explicitly access the values of window parameters via
the function window-parameter.  They aren't handled as frame
parameters are.

Re: Box cursor at EoL

[Dr Rainer Woitok]

Eli,

On Saturday, 2022-10-08 12:12:08 +0300, you wrote:

> ...
> Yes, you must explicitly access the values of window parameters via
> the function window-parameter.  They aren't handled as frame
> parameters are.

Does that mean that even though there is a way  to maintain a frame spe-
cific cursor appearance  there is no way  to maintain a  window specific
one? :-(

Sincerely,
  Rainer

Re: Box cursor at EoL

[Eli Zaretskii]

> From: Dr Rainer Woitok <rainer.woitok@gmail.com>
> Date: Sat, 8 Oct 2022 11:37:47 +0200
> Cc: help-gnu-emacs@gnu.org
> 
> > Yes, you must explicitly access the values of window parameters via
> > the function window-parameter.  They aren't handled as frame
> > parameters are.
> 
> Does that mean that even though there is a way  to maintain a frame spe-
> cific cursor appearance  there is no way  to maintain a  window specific
> one? :-(

??? I don't understand: the code which manipulates the cursor
appearance is your own code, so why is it a problem for it to access a
window parameter via a dedicated function call?  What am I missing?

Re: Box cursor at EoL

[Stefan Monnier via Users list for the GNU Emacs text editor]

>> Yes, you must explicitly access the values of window parameters via
>> the function window-parameter.  They aren't handled as frame
>> parameters are.
>
> Does that mean that even though there is a way  to maintain a frame spe-
> cific cursor appearance  there is no way  to maintain a  window specific
> one? :-(

Exactly: both the `cursor-type` variable and the `cursor-type`
frame-parameters are used by the redisplay code to decide how to draw
the cursor.  But the redisplay code does not look at any
window-parameter for that, so you can't change the cursor-shape on
a "per window" basis :-(

Maybe it's time for `M-x report-emacs-bug` and request a new feature.


        Stefan

Re: Box cursor at EoL

[Dr Rainer Woitok]

Stefan,

On Saturday, 2022-10-08 09:18:03 -0400, you wrote:

> ...
> > Does that mean that even though there is a way  to maintain a frame spe-
> > cific cursor appearance  there is no way  to maintain a  window specific
> > one? :-(
> 
> Exactly: both the `cursor-type` variable and the `cursor-type`
> frame-parameters are used by the redisplay code to decide how to draw
> the cursor.  But the redisplay code does not look at any
> window-parameter for that, so you can't change the cursor-shape on
> a "per window" basis :-(
> 
> Maybe it's time for `M-x report-emacs-bug` and request a new feature.

Well,  before I request  a feature more or less  only benefitting me but
turning out to require a total redesign of Emacs  I'd like to first con-
tinue this discussion here :-)

1. Am I correct in assuming that when I request to display a buffer in a
   new frame this will also create a new window in that new frame?

   If this were true, I could forget frames and just search for a way to
   make use of the  `cursor-type´ windows parameter,  because this would
   also solve the "same buffer in another frame" case.

2. Running `C-h v cursor-type´ returns

      cursor-type is a variable defined in `C source code´.

      Its value is t

      Cursor to use when this buffer is in the selected window.
      Values are interpreted as follows:

        t               use the cursor specified for the frame
        nil             don't display a cursor
        box             display a filled box cursor
        (box . SIZE)    display a filled box cursor, but make it
                        hollow if cursor is under masked image larger than
                        SIZE pixels in either dimension.
        hollow          display a hollow box cursor
        bar             display a vertical bar cursor with default width
        (bar . WIDTH)   display a vertical bar cursor with width WIDTH
        hbar            display a horizontal bar cursor with default height
        (hbar . HEIGHT) display a horizontal bar cursor with height HEIGHT
        ANYTHING ELSE   display a hollow box cursor

      WIDTH and HEIGHT can't exceed the frame’s canonical character size.

      When the buffer is displayed in a non-selected window, the
      cursor's appearance is instead controlled by the variable
      `cursor-in-non-selected-windows´.

        Automatically becomes buffer-local when set.
        You can customize this variable.
        Probably introduced at or before Emacs version 21.1.

   That clearly states that this buffer local variable  either allows to
   use no cursor,  a locally defined cursor specification  or the cursor
   specification for the frame, but nothing else.

So I'd suggest extending the above list of special values for buffer lo-
cal variable `cursor-type´ with

      frame             use the cursor specified for the frame (same as
                        t but with improved documentation value for hu-
                        man readers)
      window            use the cursor specified for the window

and to add these two additional alternatives for the value of buffer lo-
cal variable `cursor-type´ to every relevant evaluation of it.

But since buffer local variable  `cursor-type´  is defined in  `C source
code´,  there is no easy way for me to receive an impression of how much
effort this change would require.

Comments anybody?

Sincerely,
  Rainer

Re: Box cursor at EoL

[Kenneth Goldman]

On 10/5/2022 7:44 PM, Emanuel Berg wrote:
> Eli Zaretskii wrote:
> 
>> If this is only because you want to see the trailing blanks,
>> then customize show-trailing-whitespace to a non-nil value,
>> and these trailing blanks will be shown in distinct color.
> 
> It's better to never see them, but always remove them ...
> 

In many open source communities, a change that affects
white space would be discouraged or rejected.

Re: Box cursor at EoL

[Emanuel Berg]

Kenneth Goldman wrote:

>>> If this is only because you want to see the trailing
>>> blanks, then customize show-trailing-whitespace to
>>> a non-nil value, and these trailing blanks will be shown
>>> in distinct color.
>>
>> It's better to never see them, but always remove them ...
>
> In many open source communities, a change that affects white
> space would be discouraged or rejected.

Yes, but that's from the perspective of their systems that
would denote such changes as ... changes, right? So if they
are annoyed by that, they should change their own systems that
report that ...

And even so, if we set Emacs to behave as I suggest (always
remove them), wouldn't that mean _less_ such changes are
reported (occur) in the long run?

Bottom line, it makes sense to remove them since they don't do
anyone anything good. But what sense does it make to introduce
them to source files?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Box cursor at EoL

[Anders Munch]

Emanuel Berg wrote:
>Kenneth Goldman wrote:
>> In many open source communities, a change that affects white space 
>> would be discouraged or rejected.
>
> Yes, but that's from the perspective of their systems that would denote such
> changes as ... changes, right? So if they are annoyed by that, they should
> change their own systems that report that ...

I prefer an editor that doesn't change my files unless I ask it to.

Emacs does a very good job of that.  One problem I've encountered is the default
setting of require-final-newline.  That caused me some trouble, until I figured
out to switch it off.

regards, Anders

Re: Box cursor at EoL

[Colin Baxter]

>>>>> Anders Munch <ajm@flonidan.dk> writes:

    > Emanuel Berg wrote:
    >> Kenneth Goldman wrote:
    >>> In many open source communities, a change that affects white
    >>> space would be discouraged or rejected.
    >> 
    >> Yes, but that's from the perspective of their systems that would
    >> denote such changes as ... changes, right? So if they are annoyed
    >> by that, they should change their own systems that report that
    >> ...

    > I prefer an editor that doesn't change my files unless I ask it
    > to.

    > Emacs does a very good job of that.  One problem I've encountered
    > is the default setting of require-final-newline.  That caused me
    > some trouble, until I figured out to switch it off.

I too switch off require-final-newline, but I seem to remember reading
somewhere that text files should end with a new line. I do not know
whether this was to do with style or something more significant. Does
anyone else know of this "requirement"?

Best wishes,

Colin.

Re: Box cursor at EoL

[Anders Munch]

Colin Baxter [mailto:m43cap@yandex.com] wrote:
> Anders Munch <ajm@flonidan.dk> writes:
>> Emacs does a very good job of that.  One problem I've encountered
>> is the default setting of require-final-newline.  That caused me
>> some trouble, until I figured out to switch it off.
>
> I too switch off require-final-newline, but I seem to remember reading
> somewhere that text files should end with a new line. I do not know whether
> this was to do with style or something more significant. Does anyone else know
> of this "requirement"?

It's a POSIX thing.
https://stackoverflow.com/questions/729692/why-should-text-files-end-with-a-newline
And there's a potential issue with C include files.

regards, Anders

Re: Box cursor at EoL

[Colin Baxter]

>>>>> Anders Munch <ajm@flonidan.dk> writes:

    > Colin Baxter [mailto:m43cap@yandex.com] wrote:
    >> Anders Munch <ajm@flonidan.dk> writes:
    >>> Emacs does a very good job of that.  One problem I've
    >>> encountered is the default setting of require-final-newline.
    >>> That caused me some trouble, until I figured out to switch it
    >>> off.
    >> 
    >> I too switch off require-final-newline, but I seem to remember
    >> reading somewhere that text files should end with a new line. I
    >> do not know whether this was to do with style or something more
    >> significant. Does anyone else know of this "requirement"?

    > It's a POSIX thing.
    > https://stackoverflow.com/questions/729692/why-should-text-files-end-with-a-newline
    > And there's a potential issue with C include files.

That's interesting. I have learnt something. Thank you.

Colin.

Re: Box cursor at EoL

[Kenneth Goldman]

On 10/17/2022 12:06 AM, Emanuel Berg wrote:
> Kenneth Goldman wrote:
> 
>>>> If this is only because you want to see the trailing
>>>> blanks, then customize show-trailing-whitespace to
>>>> a non-nil value, and these trailing blanks will be shown
>>>> in distinct color.
>>>
>>> It's better to never see them, but always remove them ...
>>
>> In many open source communities, a change that affects white
>> space would be discouraged or rejected.
> 
> Yes, but that's from the perspective of their systems that
> would denote such changes as ... changes, right? So if they
> are annoyed by that, they should change their own systems that
> report that ...

To git (and most version control systems), a change is a change.
The patch history should not be cluttered with changes
that don't change anything.

> 
> And even so, if we set Emacs to behave as I suggest (always
> remove them), wouldn't that mean _less_ such changes are
> reported (occur) in the long run?

No, because not every developer on a project uses emacs.
Their loss!

> 
> Bottom line, it makes sense to remove them since they don't do
> anyone anything good. But what sense does it make to introduce
> them to source files?
> 

Re: Box cursor at EoL

[Emanuel Berg]

Anders Munch wrote:

>> Yes, but that's from the perspective of their systems that
>> would denote such changes as ... changes, right? So if they
>> are annoyed by that, they should change their own systems
>> that report that ...
>
> I prefer an editor that doesn't change my files unless I ask
> it to.

Yes, but if you tell it to, by means of configuration, that's
a way of asking as well, no?

> Emacs does a very good job of that.

It's called automation ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: Box cursor at EoL

[Emanuel Berg]

Kenneth Goldman wrote:

> To git (and most version control systems), a change is
> a change. The patch history should not be cluttered with
> changes that don't change anything.

It think they could and should be tweaked so that such
changes, which should be easy to do in this case at least,
should not be considered changes.

But even more to the point, if trailing whitespace don't
change anything, why have them _at all_?

>> And even so, if we set Emacs to behave as I suggest (always
>> remove them), wouldn't that mean _less_ such changes are
>> reported (occur) in the long run?
>
> No, because not every developer on a project uses emacs.
> Their loss!

But other editors, and also the VCS that you mention, could
auto-remove them as well, I'm sure.

After that, why introduce them? Problem solved.

-- 
underground experts united
https://dataswamp.org/~incal

Re: Box cursor at EoL

[Emanuel Berg]

Colin Baxter wrote:

> I too switch off require-final-newline, but I seem to
> remember reading somewhere that text files should end with
> a new line. I do not know whether this was to do with style
> or something more significant. Does anyone else know of this
> "requirement"?

I have `require-final-newline' t and it's in my intuition as
well to add it manually, which maybe I don't need when
I have that?

Ma-an what a waste of time this has been!

:)

-- 
underground experts united
https://dataswamp.org/~incal