GNU bug report logs - #43294
28: Combine name-spaces hi-lock and hl-line

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 43294 in the body.
You can then email your comments to 43294 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Boruch Baum <boruch_baum <at> gmx.com>
To: Emacs Bug Reporting <bug-gnu-emacs <at> gnu.org>
Subject: 28: Combine name-spaces hi-lock and hl-line
Date: Wed, 9 Sep 2020 13:38:44 -0400

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 <at> gmx.com> -----

Date: Sun, 6 Sep 2020 13:51:47 -0400
From: Boruch Baum <boruch_baum <at> gmx.com>
To: Emacs-Devel List <emacs-devel <at> 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 <at> 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

Message #8 received at 43294 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: 43294 <at> debbugs.gnu.org
Subject: Re: bug#43294: 28: Combine name-spaces hi-lock and hl-line
Date: Fri, 16 Oct 2020 09:05:10 +0200

Boruch Baum <boruch_baum <at> gmx.com> writes:

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

[...]

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

There didn't seem to be much enthusiasm for this, and it seems to me
it'd be a lot of code churn for little gain.  So I'm closing this bug
report.

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.