unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Adam Porter <adam@alphapapa.net>
To: emacs-devel@gnu.org
Subject: Re: [PATCH] lisp/bookmark.el: make bookmark-fontify nil by default
Date: Mon, 13 Sep 2021 05:43:37 -0500	[thread overview]
Message-ID: <87k0jkvjqe.fsf@alphapapa.net> (raw)
In-Reply-To: CADwFkm=hwDW3oUHZxpv6Y2Q2bErvA-Vrm=qVYUhzhKsK2mSd6Q@mail.gmail.com

Stefan Kangas <stefan@marxist.se> writes:

> [That was in May.]
>
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > Please don't make this change until you hear from Lars, who examined
>> > the original patch and decided to install it.  It doesn't get more
>> > "considerate" than that.
>>
>> It does seem to be an unexpectedly (to me, at least) controversial
>> change, so perhaps it should be tweaked.  For instance, using fringe
>> markers (on frames that support that) instead of highlighting the entire
>> line, or something else that isn't that stark.
>
> This discussion sort of fizzled out with everyone, as far as I can
> tell, mostly agreeing that a fringe marker or similar might be better
> for the default behaviour.  On master, bookmark-fontify is still t,
> and the highlighting is still done by changing the background colour.
>
> In general, I think we are sometimes too cautious with turning on
> so-called "bells and whistles", so I'm actually in one sense happy to
> see that a useful new feature is enabled by default.  Yet I'm a little
> surprised that this particular feature happened to pass the bar.
>
> I personally find that highlighting the entire line is fairly
> distracting, and I'm concerned that this is not a good new default
> behavior.  If I'm wrong, and long-time users of bookmark.el thinks
> this change is great, then that's fine of course.  But just in case
> I'm right, perhaps we could wait with setting the default to t until
> Emacs 29?  That way we have a chance to wait for the new less
> intrusive fringe marker feature, which sounds harder to have many
> reservations about.
>
> WDYT?

FWIW, I'm against enabling this feature by default.  In my testing with
Emacs 28, it's been distracting and jarring.

This is especially so for me, having written a couple of packages that
use bookmark records internally and `bookmark-jump' to go to them,
Burly.el and Dogears.el.  When I jump to or "open" a bookmark made with
Burly, the highlighted line isn't generally useful or meaningful.  It
could be in Dogears, but I'd rather enable the feature in that package's
code or its bookmark records rather than universally.

(That's another issue, and forgive me if I haven't seen it mentioned
before: could this setting be controlled by a setting inside a bookmark
record?  That could be very useful, because it could be enabled just for
ones for which highlighting the line would be meaningful.)

Anyway, maybe I could let-bind `bookmark-fontify' to nil around my calls
to `bookmark-jump', but it still seems like an awkward, unexpected
default.  I can imagine seeing many questions asking something like, "I
upgraded to Emacs 28 and something in my config broke.  What are these
yellow lines in my buffers?"

I wouldn't object as much to a fringe marker being enabled by default,
although I would still wonder if it's a good default.




  parent reply	other threads:[~2021-09-13 10:43 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-18  6:20 [PATCH] lisp/bookmark.el: make bookmark-fontify nil by default Paul W. Rankin via Emacs development discussions.
2021-05-18  6:58 ` Karl Fogel
2021-05-18  8:17   ` Paul W. Rankin via Emacs development discussions.
2021-05-18  8:45     ` Eli Zaretskii
2021-05-18 10:06       ` Paul W. Rankin via Emacs development discussions.
2021-05-18 12:09         ` Eli Zaretskii
2021-05-18 12:04       ` Eli Zaretskii
2021-05-18 14:28       ` Lars Ingebrigtsen
2021-05-18 14:38         ` Eli Zaretskii
2021-05-18 14:40           ` Lars Ingebrigtsen
2021-05-19 11:59           ` Bastien
2021-05-19 13:55             ` Eli Zaretskii
2021-05-24 22:32             ` Lars Ingebrigtsen
2021-05-24 22:51               ` [External] : " Drew Adams
2021-05-18 14:43         ` Drew Adams
2021-05-18 15:07           ` Eli Zaretskii
2021-09-13  9:46         ` Stefan Kangas
2021-09-13  9:58           ` Manuel Uberti
2021-09-13 10:17             ` Stefan Kangas
2021-09-13 10:12           ` Colin Baxter
2021-09-13 15:29             ` [External] : " Drew Adams
2021-09-13 10:43           ` Adam Porter [this message]
2021-09-13 11:36           ` Lars Ingebrigtsen
2021-09-13 19:36             ` Matthias Meulien
2021-09-14  5:40               ` Colin Baxter
2021-09-14 11:15               ` Lars Ingebrigtsen
2021-09-14 11:46                 ` Eli Zaretskii
2021-09-14 11:54                   ` Lars Ingebrigtsen
2021-09-14 11:52                 ` miha
2021-09-14 11:56                   ` Lars Ingebrigtsen
2021-09-14 14:44                     ` miha
2021-09-15  7:59                       ` Lars Ingebrigtsen
2021-05-18 10:49     ` Basil L. Contovounesios
2021-05-18 11:08       ` Paul W. Rankin via Emacs development discussions.
2021-05-19 12:00       ` Bastien
2021-05-19 12:58         ` Gregor Zattler
2021-05-18 10:49 ` Basil L. Contovounesios
2021-05-19 12:00 ` Paul W. Rankin via Emacs development discussions.
2021-05-19 14:15   ` Eli Zaretskii

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=87k0jkvjqe.fsf@alphapapa.net \
    --to=adam@alphapapa.net \
    --cc=emacs-devel@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).