all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Boruch Baum <boruch_baum@gmx.com>
To: 43294@debbugs.gnu.org
Subject: bug#43294: 28: Combine name-spaces hi-lock and hl-line
Date: Wed, 9 Sep 2020 13:38:44 -0400	[thread overview]
Message-ID: <20200909173844.7r4vfp4taopfacmb@E15-2016.optimum.net> (raw)


Here a duplicate posting of several messages from the emacs-devel list so the
request doesn't get lost thereq. Should the project
decide to approve this and choose which to alias, I could do the
coding...

----- Forwarded message from Boruch Baum <boruch_baum@gmx.com> -----

Date: Sun, 6 Sep 2020 13:51:47 -0400
From: Boruch Baum <boruch_baum@gmx.com>
To: Emacs-Devel List <emacs-devel@gnu.org>
Subject: name-space consistency
User-Agent: NeoMutt/20180716

Slightly apropos the current thread opening discussion of things that
could be done for emacs v28...

Here's an example of an annoying and persistently vexing name-space
inconsistency: to highlight based upon a regexp in a buffer, one uses
functions from package hi-lock (that a lower-case 'i', not an 'ell') and
to highlight the current line within a buffer one uses functions from
package hl-line (that's an 'ell', not a lower-case 'i').

Unless you use both often (or have a memory superior to mine), you're
bound to mis-type hl-lock or hi-line.

Would the project consider aliasing and deprecating one of those
name-spaces? Or breaking backward-compatibility and just refactoring
one?

----- End forwarded message -----


On 2020-09-06 21:04, Eli Zaretskii wrote:
> > Date: Sun, 6 Sep 2020 13:51:47 -0400
> > From: Boruch Baum <boruch_baum@gmx.com>
> >
> > Unless you use both often (or have a memory superior to mine), you're
> > bound to mis-type hl-lock or hi-line.
> >
> > Would the project consider aliasing and deprecating one of those
> > name-spaces? Or breaking backward-compatibility and just refactoring
> > one?
>
> The latter is out of the question.  The former can be done if there's
> enough support for it (but expect some dispute regarding which
> variant to prefer ;-).

----- End forwarded message -----

On 2020-09-06 14:50, Boruch Baum wrote:
> At this point, the 'measured' support on the list is 100%. If you accept
> and wait for the mail-in ballots, the final results could take months...
>

----- End forwarded message -----

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0





             reply	other threads:[~2020-09-09 17:38 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-09 17:38 Boruch Baum [this message]
2020-10-16  7:05 ` bug#43294: 28: Combine name-spaces hi-lock and hl-line Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20200909173844.7r4vfp4taopfacmb@E15-2016.optimum.net \
    --to=boruch_baum@gmx.com \
    --cc=43294@debbugs.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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.