Add some aliases for re-related functions

Add some aliases for re-related functions

[Yuan Fu]

While debating whether it’s effective to add prefixes to increase discoverability, lets start with incremental and uncontroversial changes. Let’s start from re-related functions since it seems that many people agree on this. Here is a list of functions that I think could benefit from an alias. 

replace-regexp-in-string	re-replace-in-string
replace-match			re-replace-match
string-match			re-search-in-string
string-match-p			re-match-in-string-p
match-string			re-matched-string
match-string-no-properties	re-matched-string-no-properties
match-beginning			re-match-beginning
match-end			re-match-end

looking-at			re-match-after-point
looking-back			re-match-before-point
looking-at-p			re-match-after-point-p
posix-search-forward		re-posix-search-forward
posix-search-backward		re-posix-search-backward
posix-looking-at		re-posix-looking-at
posix-search-in-string		re-posix-search-in-string

Let’s do it like this: if you don’t like adding alias to a certain function (strongly), call it out and we will remove it from the list for now. Then we should have a small list that everybody agrees upon (or at least no one absolutely hates). 

And please do not drift the topic away in this thread, which hinders the original purpose of the thread. Let’s focus on these functions and only these functions.

Yuan

Re: Add some aliases for re-related functions

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Sat, 2 May 2020 14:28:08 -0400
> 
> While debating whether it’s effective to add prefixes to increase discoverability, lets start with incremental and uncontroversial changes. Let’s start from re-related functions since it seems that many people agree on this. Here is a list of functions that I think could benefit from an alias. 
> 
> replace-regexp-in-string	re-replace-in-string
> replace-match			re-replace-match
> string-match			re-search-in-string
> string-match-p			re-match-in-string-p
> match-string			re-matched-string
> match-string-no-properties	re-matched-string-no-properties
> match-beginning			re-match-beginning
> match-end			re-match-end
> 
> looking-at			re-match-after-point
> looking-back			re-match-before-point
> looking-at-p			re-match-after-point-p
> posix-search-forward		re-posix-search-forward
> posix-search-backward		re-posix-search-backward
> posix-looking-at		re-posix-looking-at
> posix-search-in-string		re-posix-search-in-string

Is "re-" really a useful prefix?  What newbie will type "re-" when
they need regexp-related functions?  Where would they get the idea
that "re" stands for "regular expression"?

Re: Add some aliases for re-related functions

[Yuan Fu]

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

> 
> Is "re-" really a useful prefix?  What newbie will type "re-" when
> they need regexp-related functions?  Where would they get the idea
> that "re" stands for "regular expression”?

Just as an example, since I started programming with Python, I’m quite familiar with “re”. “Regexp” is also fine, I don’t have a strong opinion on this (especially for there are quite a few regexp-prefixed functions in Elisp).

Yuan



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

Re: Add some aliases for re-related functions

[Alan Mackenzie]

Hello, Yuan.

On Sat, May 02, 2020 at 14:28:08 -0400, Yuan Fu wrote:
> While debating whether it’s effective to add prefixes to increase
> discoverability, lets start with incremental and uncontroversial
> changes.

Ha!  No chance!  ;-(

I don't believe these proposed changes will increase discoverability to
any important extent.  More importantly, they will decrease the
usability of these functions, as they will be more of a hassle to type
in and (more importantly) make the functions they are in more difficult
to read.

> Let’s start from re-related functions since it seems that many people
> agree on this. Here is a list of functions that I think could benefit
> from an alias. 

> replace-regexp-in-string	re-replace-in-string
> replace-match			re-replace-match
> string-match			re-search-in-string
> string-match-p			re-match-in-string-p
> match-string			re-matched-string
> match-string-no-properties	re-matched-string-no-properties
> match-beginning			re-match-beginning
> match-end			re-match-end

> looking-at			re-match-after-point
> looking-back			re-match-before-point
> looking-at-p			re-match-after-point-p
> posix-search-forward		re-posix-search-forward
> posix-search-backward		re-posix-search-backward
> posix-looking-at		re-posix-looking-at
> posix-search-in-string		re-posix-search-in-string

> Let’s do it like this: if you don’t like adding alias to a certain
> function (strongly), call it out and we will remove it from the list
> for now.

I strongly object to those aliases which make the function name longer.
I particularly object to `re-match-after-point' for `looking-at'.  Not
only is it much longer, it lacks the instant readibility of looking-at,
and the slightly humorous notion of "looking", as though with ones eyes.
I particularly object to `re-matched-string', which has double the
number of syllables in it as the original.

As a small point, you've erased the commonality between
match-beginning/end and match-string.  This is a bad thing.

> Then we should have a small list that everybody agrees upon (or at
> least no one absolutely hates). 

I hate your list.  ;-)  (Nothing personal in that.)

> And please do not drift the topic away in this thread, which hinders
> the original purpose of the thread. Let’s focus on these functions and
> only these functions.

As long as people do not take for granted that introducing lots of
aliases is a good thing.  I believe it is not.

> Yuan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Add some aliases for re-related functions

[Yuan Fu]

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



> On May 2, 2020, at 3:29 PM, Alan Mackenzie <acm@muc.de> wrote:
> 
> Hello, Yuan.
> 
> On Sat, May 02, 2020 at 14:28:08 -0400, Yuan Fu wrote:
>> While debating whether it’s effective to add prefixes to increase
>> discoverability, lets start with incremental and uncontroversial
>> changes.
> 
> Ha!  No chance!  ;-(
> 
> I don't believe these proposed changes will increase discoverability to
> any important extent.  More importantly, they will decrease the
> usability of these functions, as they will be more of a hassle to type
> in and (more importantly) make the functions they are in more difficult
> to read.
> 
>> Let’s start from re-related functions since it seems that many people
>> agree on this. Here is a list of functions that I think could benefit
>> from an alias. 
> 
>> replace-regexp-in-string	re-replace-in-string
>> replace-match			re-replace-match
>> string-match			re-search-in-string
>> string-match-p			re-match-in-string-p
>> match-string			re-matched-string
>> match-string-no-properties	re-matched-string-no-properties
>> match-beginning			re-match-beginning
>> match-end			re-match-end
> 
>> looking-at			re-match-after-point
>> looking-back			re-match-before-point
>> looking-at-p			re-match-after-point-p
>> posix-search-forward		re-posix-search-forward
>> posix-search-backward		re-posix-search-backward
>> posix-looking-at		re-posix-looking-at
>> posix-search-in-string		re-posix-search-in-string
> 
>> Let’s do it like this: if you don’t like adding alias to a certain
>> function (strongly), call it out and we will remove it from the list
>> for now.
> 
> I strongly object to those aliases which make the function name longer.
> I particularly object to `re-match-after-point' for `looking-at'.  Not
> only is it much longer, it lacks the instant readibility of looking-at,
> and the slightly humorous notion of "looking", as though with ones eyes.
> I particularly object to `re-matched-string', which has double the
> number of syllables in it as the original.
> 
> As a small point, you've erased the commonality between
> match-beginning/end and match-string.  This is a bad thing.
> 
>> Then we should have a small list that everybody agrees upon (or at
>> least no one absolutely hates). 
> 
> I hate your list.  ;-)  (Nothing personal in that.)
> 
>> And please do not drift the topic away in this thread, which hinders
>> the original purpose of the thread. Let’s focus on these functions and
>> only these functions.
> 
> As long as people do not take for granted that introducing lots of
> aliases is a good thing.  I believe it is not.
> 
>> Yuan
> 
> -- 
> Alan Mackenzie (Nuremberg, Germany).

That’s ok. I guess my plan failed. 

Yuan

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

Re: Add some aliases for re-related functions

[Philippe Vaucher]

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

>
> On Sat, May 02, 2020 at 14:28:08 -0400, Yuan Fu wrote:
> > While debating whether it’s effective to add prefixes to increase
> > discoverability, lets start with incremental and uncontroversial
> > changes.
>
> Ha!  No chance!  ;-(
>
> I don't believe these proposed changes will increase discoverability to
> any important extent.  More importantly, they will decrease the
> usability of these functions, as they will be more of a hassle to type
> in and (more importantly) make the functions they are in more difficult
> to read.
>

Just wanted to explicit that this assume we know both function already. If
I don't know `posix-search-forward` but know one exists, but cannot
remember if it's regexp-search-posix-forward or posix-regexp-forward or
forward-search-posix, in Yuan's proposal I could "C-h f re- TAB posix TAB
and select "re-posix-search-forward" quickly.

Without that I have to C-h d "regexp posix" and curse because it returns no
result (Eli <--- please fix this), then search for C-h d posix and only
then find it.



> I strongly object to those aliases which make the function name longer.
> I particularly object to `re-match-after-point' for `looking-at'.  Not
> only is it much longer, it lacks the instant readibility of looking-at,
> and the slightly humorous notion of "looking", as though with ones eyes.
> I particularly object to `re-matched-string', which has double the
> number of syllables in it as the original.
>

Just to be clear, you don't like aliases because if they were to be used
you'd hate reading code using them, correct?
I mean you agree they won't take away your ability to use the old names?

Philippe

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

Re: Add some aliases for re-related functions

[Philippe Vaucher]

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

>
> Without that I have to C-h d "regexp posix" and curse because it returns
> no result (Eli <--- please fix this), then search for C-h d posix and only
> then find it.
>

FYI none of "posix regexp", "posix search" or "posix forward" in C-h d
returns any result (expected to find `posix-search-forward` with the later).

>

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

Re: Add some aliases for re-related functions

[Alan Mackenzie]

Hello, Philippe.

On Sat, May 02, 2020 at 22:10:29 +0200, Philippe Vaucher wrote:

> > On Sat, May 02, 2020 at 14:28:08 -0400, Yuan Fu wrote:
> > > While debating whether it’s effective to add prefixes to increase
> > > discoverability, lets start with incremental and uncontroversial
> > > changes.

> > Ha!  No chance!  ;-(

> > I don't believe these proposed changes will increase discoverability
> > to any important extent.  More importantly, they will decrease the
> > usability of these functions, as they will be more of a hassle to
> > type in and (more importantly) make the functions they are in more
> > difficult to read.


> Just wanted to explicit that this assume we know both function already.

I don't think it does.

> If I don't know `posix-search-forward` but know one exists, but cannot
> remember if it's regexp-search-posix-forward or posix-regexp-forward or
> forward-search-posix, in Yuan's proposal I could "C-h f re- TAB posix
> TAB and select "re-posix-search-forward" quickly.

In the current Emacs you can type in C-h f *posix<TAB> and one of the
alternatives (there are five) is posix-search-forward.

But just how important are such search facilities, really?

> Without that I have to C-h d "regexp posix" and curse because it
> returns no result (Eli <--- please fix this), then search for C-h d
> posix and only then find it.

See above.  If anything, the number of different ways to search for
function names might be considered confusing, but that's a separate
matter.

> > I strongly object to those aliases which make the function name longer.
> > I particularly object to `re-match-after-point' for `looking-at'.  Not
> > only is it much longer, it lacks the instant readibility of looking-at,
> > and the slightly humorous notion of "looking", as though with ones eyes.
> > I particularly object to `re-matched-string', which has double the
> > number of syllables in it as the original.


> Just to be clear, you don't like aliases because if they were to be used
> you'd hate reading code using them, correct?

I spend a fair amount of time debugging, other people's code as well as
my own.  If these long aliases get mechanically swapped in (as I presume
is the intention), as well as having to decypher the new names, there
will be more occasions when a line of code no longer fits within my 78
character wide follow-mode screen.  Hassle.

Debugging, which is already difficult enough, will get more difficult.

> I mean you agree they won't take away your ability to use the old names?

This old one!  I disagree with you entirely, here.  I debug other
people's code as well as my own.  I'd have to put up with
"re-match-after-point" and friends, thus losing the ability to "use" the
current names.

And there's a good chance some "helpful" person will decide it's time to
purge the traditional names from all code, including my code.

Anyhow, why not look at existing examples from history?

On 1991-07-25, Jim Blandy introduced the alias `search-forward-regexp'
for `re-search-forward'.  Why?  Lost in the mists of time.  Possibly for
the same reasons people are advancing now - make all the search functions
begin with "search-" for supposed easier searching (of their names).  In
master we currently have 3534 occurences of re-search-forward and 134 of
search-forward-regexp.  Would anybody here argue that Emacs is the better
for these 134 alternatively named function calls?  I'd say it was a
mistake, and there is nothing positive to offset the confusion.

Or `delete-backward-char' and its alias `backward-delete-char'.  We have,
respectively, 5 and 36 uses.  To me, this is just confusion, whatever the
original reason was for these aliases.

I say we shouldn't add to such confusion.

> Philippe

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Add some aliases for re-related functions

[Stefan Monnier]

> Is "re-" really a useful prefix?

It's convenient.  And as I explained a minute ago, I don't think we need
to choose prefix which someone will "naturally" come up with.
The important part is that the same prefix be used for all the related
functions, so once you know the prefix you can find the rest.


        Stefan

Re: Add some aliases for re-related functions

[Stefan Monnier]

> While debating whether it’s effective to add prefixes to increase
> discoverability, lets start with incremental and uncontroversial
> changes. Let’s start from re-related functions since it seems that many
> people agree on this. Here is a list of functions that I think could benefit
> from an alias. 

I don't have an opinion on the "re-" vs "regexp-" prefix, so I'll
concentrate on the non-prefix part, where the problem is to try and keep
things short.

> replace-regexp-in-string	re-replace-in-string

LGTM.

> replace-match			re-replace-match

Maybe this can be shortened to `re-replace`?

> string-match			re-search-in-string
> string-match-p		re-match-in-string-p

Hmm... a bit long for my taste.  How 'bout `re-search(-p)`?

> match-string			re-matched-string
> match-string-no-properties	re-matched-string-no-properties
> match-beginning		re-match-beginning
> match-end			re-match-end

How 'bout `re-submatch(-no-properties|beg|end)`?

> looking-at			re-match-after-point
> looking-back			re-match-before-point

[ I'm trying to use "search" and "match" in the way it's used in
  traditional regexp libraries.  ]

`re-match` and `re-match-back`?

The problem with this is that I proposed `re-search` to apply to strings
whereas I now propose `re-match` to apply to buffers.  So maybe it
should be `re-match-forward` and `re-match-backward`?

OTOH I really want to discourage the use of `looking-back` because it's
a inefficient hack with a weird semantics, so giving it a name symmetric
to that of `looking-at` is a bad idea.

> posix-		re-posix-

Sounds good, but it should also follow the renaming of the non-posix
version of the function.


        Stefan

Re: Add some aliases for re-related functions

[Philippe Vaucher]

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

> > Just to be clear, you don't like aliases because if they were to be used
> > you'd hate reading code using them, correct?
>
> (snip)
>
> > I mean you agree they won't take away your ability to use the old names?
>
> This old one!  I disagree with you entirely, here.  I debug other
> people's code as well as my own.  I'd have to put up with
> "re-match-after-point" and friends, thus losing the ability to "use" the
> current names.

I think you misunderstood me there. Literally one sentence ago I said that
you don't like aliases because you'd dislike reading code using them, so I
understood your concern. I also find your definition of "use" a bit
surprising, but ok I note that for you "use" means "write code with that
name as well as read code with that name". In my definition it just means
"write code with that name".

> And there's a good chance some "helpful" person will decide it's time to
> purge the traditional names from all code, including my code.

That's indeed a valid concern. That said at the current pace of how things
goes on that topic, I think even if *some* things were to change your code
would still be untouched for at least 20 years :-)

> Anyhow, why not look at existing examples from history?
>
> On 1991-07-25, Jim Blandy introduced the alias `search-forward-regexp'
> for `re-search-forward'.  Why?  Lost in the mists of time.  Possibly for
> the same reasons people are advancing now - make all the search functions
> begin with "search-" for supposed easier searching (of their names).  In
> master we currently have 3534 occurences of re-search-forward and 134 of
> search-forward-regexp.  Would anybody here argue that Emacs is the better
> for these 134 alternatively named function calls?  I'd say it was a
> mistake, and there is nothing positive to offset the confusion.

Interesting. Is one of the alias deprecated now? What prevents us from
massively rename every search-forward-regexp to re-search-forward? I
understand it's not your point but I don't understand why this isn't fixed
yet.

> Or `delete-backward-char' and its alias `backward-delete-char'.  We have,
> respectively, 5 and 36 uses.  To me, this is just confusion, whatever the
> original reason was for these aliases.

Same question as above.

> I say we shouldn't add to such confusion.

That's an interesting point. At the same time it gives me this impression
that following this logic everything is written in stone forever because
any change would be confusing.

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

Re: Add some aliases for re-related functions

[Dmitry Gutov]

Allow me to bikeshed a little too.

On 03.05.2020 00:33, Stefan Monnier wrote:
>> While debating whether it’s effective to add prefixes to increase
>> discoverability, lets start with incremental and uncontroversial
>> changes. Let’s start from re-related functions since it seems that many
>> people agree on this. Here is a list of functions that I think could benefit
>> from an alias.
> 
> I don't have an opinion on the "re-" vs "regexp-" prefix, so I'll
> concentrate on the non-prefix part, where the problem is to try and keep
> things short.

Same.

>> replace-regexp-in-string	re-replace-in-string
> 
> LGTM.

+

>> replace-match			re-replace-match
> 
> Maybe this can be shortened to `re-replace`?

re-replace sounds like it will take both the regexp and the replacement 
as argument. The 'match' word is meaningful.

>> string-match			re-search-in-string
>> string-match-p		re-match-in-string-p
> 
> Hmm... a bit long for my taste.  How 'bout `re-search(-p)`?

re-match and re-match-p?

>> match-string			re-matched-string
>> match-string-no-properties	re-matched-string-no-properties
>> match-beginning		re-match-beginning
>> match-end			re-match-end
> 
> How 'bout `re-submatch(-no-properties|beg|end)`?

It's ok. But I'd just prepend 're-' to existing functions instead.

>> looking-at			re-match-after-point
>> looking-back			re-match-before-point
> 
> [ I'm trying to use "search" and "match" in the way it's used in
>    traditional regexp libraries.  ]

Guess I'm unfamiliar with said libraries. I'd suggest re-looking-at and 
re-looking-back (or whatever, like, don't create an alias for the last 
one if we don't want to).

> `re-match` and `re-match-back`?

Both sound like they will move point.

> The problem with this is that I proposed `re-search` to apply to strings
> whereas I now propose `re-match` to apply to buffers.  So maybe it
> should be `re-match-forward` and `re-match-backward`?

It's fairly hard to distinguish, without reading the docs, from 
re-search-forward and -backward.

Re: Add some aliases for re-related functions

[Eric Abrahamsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Allow me to bikeshed a little too.

[...]

>> The problem with this is that I proposed `re-search` to apply to strings
>> whereas I now propose `re-match` to apply to buffers. So maybe it
>> should be `re-match-forward` and `re-match-backward`?
>
> It's fairly hard to distinguish, without reading the docs, from
> re-search-forward and -backward.

I know the last thing we need is more bikeshedding, but to me "match"
sounds very much like it should work on strings, and "search" in
buffers. You match one thing with another. You search a place for a
thing.

Barely 2¢...

RE: Add some aliases for re-related functions

[Drew Adams]

> > Is "re-" really a useful prefix?
> 
> It's convenient.  And as I explained a minute ago, I don't think we
> need to choose prefix which someone will "naturally" come up with.
> The important part is that the same prefix be used for all the related
> functions, so once you know the prefix you can find the rest.

That's pretty much true whether `re-' is used
as prefix or is elsewhere in the name, as long
as it is set off using a hyphen.  E.g.,
`nonincremental-re-search-forward',
`Info-following-node-name-re'.

(No, it's not always the case: `ange-ftp-re-read-dir',
`message-strip-subject-re'.  But some functions that
use `re-' are anyway misnamed - should be
`ange-ftp-reread-dir', for example.)

Re: Add some aliases for re-related functions

[Stefan Monnier]

> On 1991-07-25, Jim Blandy introduced the alias `search-forward-regexp'
> for `re-search-forward'.

Oh, right, I hate that alias.

> Why?  Lost in the mists of time.  Possibly for the same reasons people
> are advancing now - make all the search functions begin with "search-"
> for supposed easier searching (of their names).

Could be.  I always assumed it was meant for M-x use (i.e. for
non-programmer users) rather than for use in Elisp code.

> Or `delete-backward-char' and its alias `backward-delete-char'.  We have,
> respectively, 5 and 36 uses.  To me, this is just confusion, whatever the
> original reason was for these aliases.

I can also come up with bad examples.  I don't think it makes it
undesirable to add aliases.  Rather it argues for making sure you don't
forget to mark one of the two as obsolete.


        Stefan

RE: Add some aliases for re-related functions

[Drew Adams]

> > replace-regexp-in-string	re-replace-in-string
> LGTM.
> 
> > replace-match			re-replace-match
> Maybe this can be shortened to `re-replace`?
> 
> > string-match			re-search-in-string
> > string-match-p		re-match-in-string-p
> Hmm... a bit long for my taste.  How 'bout `re-search(-p)`?
> 
> > match-string			re-matched-string
> > match-string-no-properties	re-matched-string-no-properties
> > match-beginning		re-match-beginning
> > match-end			re-match-end
> How 'bout `re-submatch(-no-properties|beg|end)`?
> 
> > looking-at			re-match-after-point
> > looking-back			re-match-before-point
> [ I'm trying to use "search" and "match" in the way it's used in
>   traditional regexp libraries.  ]
> `re-match` and `re-match-back`?
> 
> The problem with this is that I proposed `re-search` to apply to
> strings whereas I now propose `re-match` to apply to buffers.  So maybe it
> should be `re-match-forward` and `re-match-backward`?
> 
> OTOH I really want to discourage the use of `looking-back` because it's
> a inefficient hack with a weird semantics, so giving it a name
> symmetric to that of `looking-at` is a bad idea.
> 
> > posix-		re-posix-
> Sounds good, but it should also follow the renaming of the non-posix
> version of the function.

I really cannot wait till you get to renaming
functions concerning lines: `line-...' or
perhaps `lines-...'.  And their aliases...

keep-lines                -> lines-keep-re?
                             lines-re-keep?
                             re-lines-keep?
                             re-keep-lines?
delete-non-matching-lines -> lines-delete-re-non-matching?
                             lines-re-delete-non-matching?
                             re-lines-delete-non-matching?
                             re-delete-non-matching-lines?
flush-lines               -> lines-flush-re?
                             lines-re-flush?
                             re-lines-flush?
                             re-flush-lines?
delete-matching-lines     -> lines-delete-re-matching?
                             lines-re-delete-matching?
                             re-lines-delete-matching?
                             re-delete-matching-lines?

There'll truly be no end to this fun.  I can
finally imagine what the expected hoard of new
Emacs developers will be working on.

Are we having fun yet?

;-)

Re: Add some aliases for re-related functions

[Stefan Monnier]

>> [ I'm trying to use "search" and "match" in the way it's used in
>>    traditional regexp libraries.  ]
> Guess I'm unfamiliar with said libraries. I'd suggest re-looking-at and
> re-looking-back (or whatever, like, don't create an alias for the last 
> one if we don't want to).

Most of the literature on regular expressions concentrates on the
problem of finding whether a given string matches a given regexp, where
"matching" here means that the regexp matches the whole string.

Think of it as the case where the regexp starts with \` and ends with \'

Then there's the relaxation of "finding the longest match" (what we
call `looking-at`) and then "finding the leftmost longest match" (what
we call `string-match`).

Those two have traditionally be named `re_match` and `re_search`
respectively in C libraries (as can be seen in `src/regexp-emacs.c`).


        Stefan


PS: BTW, `looking-back` doesn't do a "match" of the "longest match that
ends at point" but a "search" for the "rightmost longest match that ends
at point" since it uses `re-search-backward` internally.

Re: Add some aliases for re-related functions

[Dmitry Gutov]

On 03.05.2020 01:49, Stefan Monnier wrote:
>>> [ I'm trying to use "search" and "match" in the way it's used in
>>>     traditional regexp libraries.  ]
>> Guess I'm unfamiliar with said libraries. I'd suggest re-looking-at and
>> re-looking-back (or whatever, like, don't create an alias for the last
>> one if we don't want to).
> 
> Most of the literature on regular expressions concentrates on the
> problem of finding whether a given string matches a given regexp, where
> "matching" here means that the regexp matches the whole string.

Right. Buffers are an Emacs specific.

> Think of it as the case where the regexp starts with \` and ends with \'
> 
> Then there's the relaxation of "finding the longest match" (what we
> call `looking-at`) and then "finding the leftmost longest match" (what
> we call `string-match`).

looking-at being a special case of re-search-forward, I take?

> Those two have traditionally be named `re_match` and `re_search`
> respectively in C libraries (as can be seen in `src/regexp-emacs.c`).

Yes, ok. But we also need names to distinguish that things happen in a 
buffer. So far we've used 'search' for those.

Using the term 'search' for matching in strings might be a significant 
change, given existing expectations.

> PS: BTW, `looking-back` doesn't do a "match" of the "longest match that
> ends at point" but a "search" for the "rightmost longest match that ends
> at point" since it uses `re-search-backward` internally.

It's a weird function, I agree. Though it's proved to be a handy one.

Re: Add some aliases for re-related functions

[Stefan Monnier]

> I really cannot wait till you get to renaming
> functions concerning lines: `line-...' or
> perhaps `lines-...'.  And their aliases...

I must say I find this mildly offensive.  It's basically a strawman argument.

All of us arguing in favor of structuring the namespace have made it
very clear we have no intention of applying this everywhere.

Please stop.


        Stefan

Re: Add some aliases for re-related functions

[Stefan Monnier]

>> Think of it as the case where the regexp starts with \` and ends with \'
>> Then there's the relaxation of "finding the longest match" (what we
>> call `looking-at`) and then "finding the leftmost longest match" (what
>> we call `string-match`).
>
> looking-at being a special case of re-search-forward, I take?

Not sure what you mean by that.  `re-search-forward` is in the same
category as `string-match`, i.e. it's a *search* operation, whereas
`looking-at` is a *match* operation.

IOW a "match" operation is like a "search" but where `match-beginning`.

Algorithmically, the two are close, but there's a bit more work to go
from one to the other than meets the eye:

If you take a regexp and turn it into a DFA in the usual way, you get an
automaton that can trivially (and in O(n) time) give you either the
shortest match or the longest match.  But if you want it to search, you
have to add a loop around it to try matching at every possible start
position, which brings the complexity to O(n²) :-(

To fix that you can try and compile ".*RE" instead of "RE" and that will
give you an automaton that can do the search or "RE" in O(n) time, but
it won't directly give you the "leftmost longest match" (instead it can
directly give you "the match whose match-end is closest" and "the match
whose match-end is furthest").  So to get the desired "leftmost longest
match", you have to work a bit harder yet.

Note: Emacs's regexp engine isn't based on a DFA, and doesn't try and
use the second option: our engine basically only does "matching" and to
get the search behavior we add a loop around it, so algorithmically,
`looking-at` and `string-match/re-search-forward` are quite different.

Notice that we don't really have the equivalent of `looking-at`
on strings currently :-(

>> Those two have traditionally be named `re_match` and `re_search`
>> respectively in C libraries (as can be seen in `src/regexp-emacs.c`).
> Yes, ok. But we also need names to distinguish that things happen in
> a buffer. So far we've used 'search' for those.
> Using the term 'search' for matching in strings might be a significant
> change, given existing expectations.

Yes, it's unfortunate.  Maybe we could/should merge them to clarify:

    (re-match REGEXP &optional STRING LIMIT START)
    (re-search REGEXP &optional STRING LIMIT START)

would be like `looking-at` but would operate on STRING instead of
`current-buffer` if STRING is non-nil.  START defaults to point for
current-buffer and 0 for a string.

Compared to re-search-forward, this lacks the NOERROR and the COUNT args.
We could add yet more optional args, but this is getting ugly.  Not sure
how important these are, tho.
Or maybe we could change the optional START arg so it means "START" when used on
a string and it means something else (NOERROR or COUNT) when used in
a buffer (yucky)?

>> PS: BTW, `looking-back` doesn't do a "match" of the "longest match that
>> ends at point" but a "search" for the "rightmost longest match that ends
>> at point" since it uses `re-search-backward` internally.
> It's a weird function, I agree. Though it's proved to be a handy one.

Yes.  The functionality it offers is important, but in reality one would
want a "real" `looking-back` which uses a backward match, rather than
the current "backward search for a forward match" hack.  It would be
both more efficient and provide a cleaner behavior.


        Stefan

RE: Add some aliases for re-related functions

[Drew Adams]

> > I really cannot wait till you get to renaming
> > functions concerning lines: `line-...' or
> > perhaps `lines-...'.  And their aliases...
> 
> I must say I find this mildly offensive.
> It's basically a strawman argument.

It was tongue-in-cheek (whimsical exaggeration),
not a serious argument (unless someone actually
does think it could/should be done for lines).

> All of us arguing in favor of structuring the
> namespace have made it very clear we have no
> intention of applying this everywhere.
> 
> Please stop.

Sorry.  It was meant as humor, to lighten things
up.  Clearly failed at that.

It wasn't intended to be taken literally.  But
the point behind it (there was one) was just
that naming is hard.  It's not easy to find a
reasonable and consistent way to name things,
including functions.  (I think we agree about
that, at least.)

Again, sorry for any misunderstanding I caused.

Re: Add some aliases for re-related functions

[Philippe Vaucher]

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

>
> It wasn't intended to be taken literally.  But
> the point behind it (there was one) was just
> that naming is hard.  It's not easy to find a
> reasonable and consistent way to name things,
> including functions.  (I think we agree about
> that, at least.)


Yes, naming is one of the hardest thing. Still when we see names that could
be improved and where most agree shouldn't we try?

You make it sound like because naming is hard bad names are ok, or that any
new name will be barely better as naming is hard. If I strawman your
position we could name every new function as function5318759 with an
incremental number because hey naming is hard we might as well give up :-)

I'm joking of course :-)

Philippe

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

Re: Add some aliases for re-related functions

[Michael Albinus]

Drew Adams <drew.adams@oracle.com> writes:

Hi Drew,

> (No, it's not always the case: `ange-ftp-re-read-dir',
> `message-strip-subject-re'.  But some functions that
> use `re-' are anyway misnamed - should be
> `ange-ftp-reread-dir', for example.)

I doubt that ange-ftp-* functions are used outside ange-ftp.el these
days. We shouldn't be too extreme, and change such function names.

Best regards, Michael.

Re: Add some aliases for re-related functions

[Alan Mackenzie]

Hello, Philippe.

On Sat, May 02, 2020 at 23:51:13 +0200, Philippe Vaucher wrote:
> > > Just to be clear, you don't like aliases because if they were to be used
> > > you'd hate reading code using them, correct?

> > (snip)

> > > I mean you agree they won't take away your ability to use the old names?

> > This old one!  I disagree with you entirely, here.  I debug other
> > people's code as well as my own.  I'd have to put up with
> > "re-match-after-point" and friends, thus losing the ability to "use" the
> > current names.

> I think you misunderstood me there. Literally one sentence ago I said that
> you don't like aliases because you'd dislike reading code using them, so I
> understood your concern. I also find your definition of "use" a bit
> surprising, but ok I note that for you "use" means "write code with that
> name as well as read code with that name". In my definition it just means
> "write code with that name".

It's good to understand what we mean by simple words like "use".  It
seemed to me like you were regarding the reading of code as a minor
unimportant thing.  I think reading code (including all the things which
require it, such as debugging) is the most important thing we do with
code, bar executing it.

So, if by "use", you mean just "writing", I'd say that's not of the
highest importance.

> > And there's a good chance some "helpful" person will decide it's time to
> > purge the traditional names from all code, including my code.

> That's indeed a valid concern. That said at the current pace of how things
> goes on that topic, I think even if *some* things were to change your code
> would still be untouched for at least 20 years :-)

The point is that this proposal is so disruptive that ALL code will have
to change.  And all the documentation.

> > Anyhow, why not look at existing examples from history?

> > On 1991-07-25, Jim Blandy introduced the alias
> > `search-forward-regexp' for `re-search-forward'.  Why?  Lost in the
> > mists of time.  Possibly for the same reasons people are advancing
> > now - make all the search functions begin with "search-" for supposed
> > easier searching (of their names).  In master we currently have 3534
> > occurences of re-search-forward and 134 of search-forward-regexp.
> > Would anybody here argue that Emacs is the better for these 134
> > alternatively named function calls?  I'd say it was a mistake, and
> > there is nothing positive to offset the confusion.

> Interesting. Is one of the alias deprecated now? What prevents us from
> massively rename every search-forward-regexp to re-search-forward?

Nothing.  Just we can't get rid of the alias because it will be being
used by lots of external code.  Aliases are a lot easier to introduce
than to get rid of.

> I understand it's not your point but I don't understand why this isn't
> fixed yet.

> > Or `delete-backward-char' and its alias `backward-delete-char'.  We have,
> > respectively, 5 and 36 uses.  To me, this is just confusion, whatever the
> > original reason was for these aliases.

> Same question as above.

Same answer.

> > I say we shouldn't add to such confusion.

> That's an interesting point. At the same time it gives me this impression
> that following this logic everything is written in stone forever because
> any change would be confusing.

Lots of things change continually in Emacs.  Mostly, they are sensible
amendments which are restricted in scope, and well tried out before hand.

This proposal, the wholesale renaming of function names, for what purpose
seems to have been forgotten, will overturn decades of history.  Yes,
`looking-at' should stay looking-at forever, because it is an established
name and is a good name.

It is not that the proposed change would be "confusing".  It is that the
change would be bad.  Of all the things we do with source code, reading
it is the most important.  The change would render Emacs less readable.

The rationale for this change has got lost in the flurry of bikeshedding.
Eli, early on, tried to explore this rationale and come up with less
disruptive ways of achieving it.  It seems to me entirely possible that
somebody decided they wanted to rename Emacs functions, and came up with
a justification for it, rather than the other way around.

`looking-at' is a far better name than `re-matched-after-point'.  Let's
just stick with it.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Add some aliases for re-related functions

[Alan Mackenzie]

Hello, Philippe.

On Sun, May 03, 2020 at 10:05:40 +0200, Philippe Vaucher wrote:

> > It wasn't intended to be taken literally.  But
> > the point behind it (there was one) was just
> > that naming is hard.  It's not easy to find a
> > reasonable and consistent way to name things,
> > including functions.  (I think we agree about
> > that, at least.)


> Yes, naming is one of the hardest thing. Still when we see names that could
> be improved and where most agree shouldn't we try?

Most users don't agree.  Most users haven't expressed an opinion.  The
flood of bikeshedding that's gone on has been mainly between a very few
people echoing an apparent agreement between themselves.

Most importantly, Eli hasn't expressed his approval, and he's the main
person who keeps the show on the road.  Neither has Richard (as far as
I've seen), the originator of Emacs, and the person with the best
overview of its history and development.

> You make it sound like because naming is hard bad names are ok, ....

If there are bad function names in Emacs, lets fix them one by one, each
on its merits.

> .... or that any new name will be barely better as naming is hard. If
> I strawman your position we could name every new function as
> function5318759 with an incremental number because hey naming is hard
> we might as well give up :-)

re-do-something-with-regexps is different from function5318769 in
degree, but shares much of the essence.

> I'm joking of course :-)

Hmmm.

> Philippe

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Add some aliases for re-related functions

[tomas]

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

On Sun, May 03, 2020 at 09:55:26AM +0000, Alan Mackenzie wrote:

[...]

> If there are bad function names in Emacs, lets fix them one by one, each
> on its merits.

To be fair, it does make sense to have some vision as to which
direction those renames should tend to, if one wants to have
some overall consistency. Even if that direction itself changes
over time (which, of course, threatens that consistency, alas).
It's a process.

In this light, proposals like Philippe's are very valuable.
They are part of the process. Even when they explode in a
flurry of bikeshedding, that seems to be part of it too.

What I find sad is when it results on people being hurt.

Cheers
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Add some aliases for re-related functions

[Eli Zaretskii]

> From: Philippe Vaucher <philippe.vaucher@gmail.com>
> Date: Sat, 2 May 2020 22:10:29 +0200
> Cc: Yuan Fu <casouri@gmail.com>, Emacs developers <emacs-devel@gnu.org>
> 
> Just wanted to explicit that this assume we know both function already. If I don't know `posix-search-forward
> ` but know one exists, but cannot remember if it's regexp-search-posix-forward or posix-regexp-forward or
> forward-search-posix, in Yuan's proposal I could "C-h f re- TAB posix TAB and select
> "re-posix-search-forward" quickly.
> 
> Without that I have to C-h d "regexp posix" and curse because it returns no result (Eli <--- please fix this),
> then search for C-h d posix and only then find it.

I did fix this, but please note that you are using the wrong tool for
the job.  If you expect the _name_ of the function to include "posix",
then the right tool is "C-u C-h a posix RET", which gives you exactly
what you want.  "C-h d" is for when you are NOT sure the keyword will
appear in the name, and therefore widen your search to the doc string
and the list of the arguments.

Re: Add some aliases for re-related functions

[Eli Zaretskii]

> From: Philippe Vaucher <philippe.vaucher@gmail.com>
> Date: Sat, 2 May 2020 22:13:20 +0200
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> FYI none of "posix regexp", "posix search" or "posix forward" in C-h d returns any result (expected to find
> `posix-search-forward` with the later).

"C-h d" doesn't look at the names of the functions.

Re: Add some aliases for re-related functions

[조성빈]

Alan Mackenzie <acm@muc.de> 작성:

> It seems to me entirely possible that
> somebody decided they wanted to rename Emacs functions, and came up with
> a justification for it, rather than the other way around.

Very interesting, it seems to me that there’s plenty of evidence that people
want a more consistent API, but people who already ‘know’ the function names
are coming up with (IMHO weak) justifications to not ‘switch’.

Re: Add some aliases for re-related functions

[Eli Zaretskii]

> Date: Sun, 3 May 2020 09:55:26 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: Yuan Fu <casouri@gmail.com>, Stefan Monnier <monnier@iro.umontreal.ca>,
>  Drew Adams <drew.adams@oracle.com>, Emacs developers <emacs-devel@gnu.org>
> 
> Most importantly, Eli hasn't expressed his approval, and he's the main
> person who keeps the show on the road.

I stated my opinion, I gather that my English, though not my first
language, is clear enough.

More importantly, there doesn't seem to be any concrete proposal on
the table, just a lot of talk and function names here and there.
Doesn't sound to me like decision time, yet.

Re: Add some aliases for re-related functions

[Yuri Khan]

On Sun, 3 May 2020 at 21:16, Eli Zaretskii <eliz@gnu.org> wrote:

> […] please note that you are using the wrong tool for
> the job.  If you expect the _name_ of the function to include "posix",
> then the right tool is "C-u C-h a posix RET", which gives you exactly
> what you want.  "C-h d" is for when you are NOT sure the keyword will
> appear in the name, and therefore widen your search to the doc string
> and the list of the arguments.

Now this shows one aspect of the problem.

You know there are two tools, one for searching function names,
another for searching docstrings. (Also one for searching Info.) You
have developed an intuition when to use which.

An average user today believes that there should be one obvious tool
for all search needs. “Computer, show me everything I might want to
know about posix regexps, pereferably listing the one function I need
right now at the top (but I’m willing to scroll through about ten or
twenty results as I know mind reading hasn’t been perfected yet).”

Re: Add some aliases for re-related functions

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Sun, 3 May 2020 23:20:32 +0700
> Cc: Philippe Vaucher <philippe.vaucher@gmail.com>, Alan Mackenzie <acm@muc.de>, Yuan Fu <casouri@gmail.com>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> An average user today believes that there should be one obvious tool
> for all search needs. “Computer, show me everything I might want to
> know about posix regexps, pereferably listing the one function I need
> right now at the top (but I’m willing to scroll through about ten or
> twenty results as I know mind reading hasn’t been perfected yet).”

We could easily provide a command that does what both, but given that
people complain about too many hits returned by "C-h d", what do you
think will be their reaction when they see even more hits added by
"C-h a" (or vice versa)?

I said up-thread, and I repeat: all of the measures to make the
potential number of hits larger will backfire as long as we don't have
a good scoring system that almost always puts the most probable hits
in the first dozen.  No, I don't have an algorithm for that; I'm not
an expert in this field.  But I do know it's possible, because I see
it every day when I search the Internet.

Re: Add some aliases for re-related functions

[Dmitry Gutov]

On 03.05.2020 19:42, Eli Zaretskii wrote:
> I said up-thread, and I repeat: all of the measures to make the
> potential number of hits larger will backfire as long as we don't have
> a good scoring system that almost always puts the most probable hits
> in the first dozen.

Please don't assume your usage-based scoring idea is going to be good 
for everyone. Some like that, some don't.

In fact, it's going to be _terrible_ for discovering an API, simply 
because the user hasn't already used something he's looking for, yet.

 > No, I don't have an algorithm for that; I'm not
an expert in this field.  But I do know it's possible, because I see
it every day when I search the Internet.

In the meantime, we have a few existing filtering/scoring algorithms 
that people use already. And the request for prefix-based naming is 
borne out of that usage.

Re: Add some aliases for re-related functions

[Alan Mackenzie]

Hello, Stefan.

On Sat, May 02, 2020 at 18:41:04 -0400, Stefan Monnier wrote:
> > On 1991-07-25, Jim Blandy introduced the alias `search-forward-regexp'
> > for `re-search-forward'.

> Oh, right, I hate that alias.

I've been confused by it.  I don't love it either.

> > Why?  Lost in the mists of time.  Possibly for the same reasons people
> > are advancing now - make all the search functions begin with "search-"
> > for supposed easier searching (of their names).

> Could be.  I always assumed it was meant for M-x use (i.e. for
> non-programmer users) rather than for use in Elisp code.

> > Or `delete-backward-char' and its alias `backward-delete-char'.  We have,
> > respectively, 5 and 36 uses.  To me, this is just confusion, whatever the
> > original reason was for these aliases.

> I can also come up with bad examples.  I don't think it makes it
> undesirable to add aliases.  Rather it argues for making sure you don't
> forget to mark one of the two as obsolete.

It doesn't make sense to introduce an alias and immediately mark it as
obsolete.  So I think you're suggesting that heavily used and well loved
function names like looking-at and match-string should be marked obsolete.

I'm unhappy with that.  The proposed replacement names are worse for an
important thing we do with Emacs (reading code and debugging it), and
the whole reason for this proposed substitution seems to have got lost.

The discussion ought to be about what we are trying to do, whether we
should do it at all, and if so what ways there are of achieving this.
Instead it seems some people have already decided to replace function
names and are at the stage of proposing lists of replacements.  This
isn't good.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

RE: Add some aliases for re-related functions

[Drew Adams]

> > (No, it's not always the case: `ange-ftp-re-read-dir',
> > `message-strip-subject-re'.  But some functions that
> > use `re-' are anyway misnamed - should be
> > `ange-ftp-reread-dir', for example.)
> 
> I doubt that ange-ftp-* functions are used outside ange-ftp.el these
> days. We shouldn't be too extreme, and change such function names.

Definitely.  100%.

RE: Add some aliases for re-related functions

[Drew Adams]

[Again, please consider using plain-text, not HTML, in your messages.]

>> It wasn't intended to be taken literally.  But
>> the point behind it (there was one) was just
>> that naming is hard.  It's not easy to find a
>> reasonable and consistent way to name things,
>> including functions.  (I think we agree about
>> that, at least.)
>
> Yes, naming is one of the hardest thing. Still when we see names that could be improved and where most agree shouldn't we try?

Certainly we should.

We should try on a case-by-case basis, not apply
a presumed general rule with a broad brush.

(And yes, Stefan, I realize that no one is saying
to paint _everything_ with the same brush.  It's
a difference of scope/degree.)

> You make it sound like because naming is hard
> bad names are ok

How did I make it sound like that to you?

> or that any new name will be barely better
> as naming is hard.

Again, how did I make it sound like that to you?

> If I strawman your position we could name every
> new function as function5318759 with an incremental
> number because hey naming is hard we might as well
> give up :-)

I wonder what, in anything I've written, could
possibly give rise to such a strawman extension
in your mind?

> I'm joking of course :-)

If you look at the particular half-kidding examples
I showed, you might see that they're not screwball.
Nearly all of them are perfectly reasonable.  And
that's the point of showing them.

With a command such as `flush-lines', if we want to
prefix the name, just what is a good prefix?

Is the command mostly about lines (the type of data
acted on), so perhaps use prefix `lines-'?

Is it mostly about regexp-matching/searching, so
perhaps use prefix `re-'?

Is it mostly about deleting text, so perhaps use
prefix `delete-' (as in one of its aliases)?

The question's a good one.  It suggests we should
examine function names case by case.  And it
suggests there are multiple possibilities, and it's
a judgment call about what's most important for the
name.

Nowhere do I suggest we shouldn't try to get the
best names possible, just because there may not be
any perfect or correct name (impossible, as Stefan
said) or because finding the best name fit is hard
(as he also said).

I agreed with that characterization (in fact, I
emphatically applauded his phrase "hard and
impossible").  Clearly, neither I nor Stefan thinks
that just because it's hard, and ultimately
impossible, we shouldn't bother to get the best
names we can find (agree on).

https://lists.gnu.org/archive/html/emacs-devel/2020-04/msg01975.html

Re: Add some aliases for re-related functions

[Dmitry Gutov]

On 03.05.2020 06:55, Stefan Monnier wrote:
>>> Think of it as the case where the regexp starts with \` and ends with \'
>>> Then there's the relaxation of "finding the longest match" (what we
>>> call `looking-at`) and then "finding the leftmost longest match" (what
>>> we call `string-match`).
>>
>> looking-at being a special case of re-search-forward, I take?
> 
> Not sure what you mean by that.

More or less that (looking-at "abc") is basically the same as 
(re-search-forward "\\=abc"). Though maybe not internally.

> `re-search-forward` is in the same
> category as `string-match`, i.e. it's a *search* operation, whereas
> `looking-at` is a *match* operation.
> 
> IOW a "match" operation is like a "search" but where `match-beginning`.
> 
> Algorithmically, the two are close, but there's a bit more work to go
> from one to the other than meets the eye:

Thanks for the explanation.

> If you take a regexp and turn it into a DFA in the usual way, you get an
> automaton that can trivially (and in O(n) time) give you either the
> shortest match or the longest match.  But if you want it to search, you
> have to add a loop around it to try matching at every possible start
> position, which brings the complexity to O(n²) :-(
> 
> To fix that you can try and compile ".*RE" instead of "RE" and that will
> give you an automaton that can do the search or "RE" in O(n) time, but
> it won't directly give you the "leftmost longest match" (instead it can
> directly give you "the match whose match-end is closest" and "the match
> whose match-end is furthest").

But that's what we generally want in practice anyway. And in the cases 
where the desired out come is different, the regexp is probably 
ambiguous, which often means worse performance.

> Note: Emacs's regexp engine isn't based on a DFA, and doesn't try and
> use the second option: our engine basically only does "matching" and to
> get the search behavior we add a loop around it, so algorithmically,
> `looking-at` and `string-match/re-search-forward` are quite different.
> 
> Notice that we don't really have the equivalent of `looking-at`
> on strings currently :-(
> 
>>> Those two have traditionally be named `re_match` and `re_search`
>>> respectively in C libraries (as can be seen in `src/regexp-emacs.c`).
>> Yes, ok. But we also need names to distinguish that things happen in
>> a buffer. So far we've used 'search' for those.
>> Using the term 'search' for matching in strings might be a significant
>> change, given existing expectations.
> 
> Yes, it's unfortunate.  Maybe we could/should merge them to clarify:
> 
>      (re-match REGEXP &optional STRING LIMIT START)
>      (re-search REGEXP &optional STRING LIMIT START)
> 
> would be like `looking-at` but would operate on STRING instead of
> `current-buffer` if STRING is non-nil.  START defaults to point for
> current-buffer and 0 for a string.

re-search-forward also moves point, whereas string-match returns the 
index of the match start. I think it would be kinda ugly to choose among 
these behaviors based on the second argument. And if it returns point 
instead, without moving, we get an entirely different function now.

I'm not sure it's worth the changeover and retraining everybody if the 
main benefit is being more aware of the underlying algorithm complexity. 
After all, it's not too hard to make an educated guess that looking-at 
is (or at least can be) faster than re-search-forward.

>>> PS: BTW, `looking-back` doesn't do a "match" of the "longest match that
>>> ends at point" but a "search" for the "rightmost longest match that ends
>>> at point" since it uses `re-search-backward` internally.
>> It's a weird function, I agree. Though it's proved to be a handy one.
> 
> Yes.  The functionality it offers is important, but in reality one would
> want a "real" `looking-back` which uses a backward match, rather than
> the current "backward search for a forward match" hack.  It would be
> both more efficient and provide a cleaner behavior.

It suppose so. Yet, in all cases I had to rewrite looking-back calls to 
add the now-mandatory argument, the resulting time it took was fast 
enough to get lost in the measurement noise.

Maybe an optimized version could enable some new use cases, though.

Re: Add some aliases for re-related functions

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

  > replace-regexp-in-string	re-replace-in-string
  > replace-match			re-replace-match
  > string-match			re-search-in-string
  > string-match-p			re-match-in-string-p
  > match-string			re-matched-string
  > match-string-no-properties	re-matched-string-no-properties
  > match-beginning			re-match-beginning
  > match-end			re-match-end

  > looking-at			re-match-after-point
  > looking-back			re-match-before-point
  > looking-at-p			re-match-after-point-p
  > posix-search-forward		re-posix-search-forward
  > posix-search-backward		re-posix-search-backward
  > posix-looking-at		re-posix-looking-at
  > posix-search-in-string		re-posix-search-in-string

Some of these are painfully long.

This sort of systematization is desirable, all else being equal.  But
we have to minimize the costs also, and a longer name is a real cost.

The functions whose names start with 'match-' are not limited to
regexps.  match-beginning and match-end are often used after
search-forward.  For brevity, I think it is better to keep
those names unchanged.

  > replace-match			match-replace

That puts it into the 'match-' group, where it fits well.
It, like those others, is for operating on a match found by
another function.

  > replace-regexp-in-string		replace-regexp-string

That is parallel to replace-regexp.  If we don't rename
replace-regexp, let's pick a name for this that parallels it.

  > string-match			re-search-string
  > string-match-p			re-search-string-p

Since what these do is search, they may as well be called 'search'.
We can reserve 'match' to mean an anchored match.

  > looking-at				re-match
  > looking-back			re-match-back
  > looking-at-p			re-match-p

Those are nice and short.

  > posix-search-forward		re-search-forward-posix
  > posix-search-backward		re-search-backward-posix
  > posix-looking-at			re-match-posix
  > posix-string-match			re-search-string-posix


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

Re: Add some aliases for re-related functions

[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 really cannot wait till you get to renaming
  > > > functions concerning lines: `line-...' or
  > > > perhaps `lines-...'.  And their aliases...
  > > 
  > > I must say I find this mildly offensive.
  > > It's basically a strawman argument.

  > It was tongue-in-cheek (whimsical exaggeration),
  > not a serious argument (unless someone actually
  > does think it could/should be done for lines).

Whimsical exaggeration, when it occurs in the
contest of a disagreement, can easily be percieved
by the one disagreed with as an unfair criticism
of something perse didn't say.

I suggest we all make an point of avoiding exaggeration
in discussions where there is a disagreement or argument going on.

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

Re: Add some aliases for re-related functions

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

  > "C-h d" doesn't look at the names of the functions.

Should we change it to look at their names as well as their documentation?
I have a feeling that would be more useful than the current definition.

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

Re: Add some aliases for re-related functions

[Stefan Monnier]

>> give you an automaton that can do the search or "RE" in O(n) time, but
>> it won't directly give you the "leftmost longest match" (instead it can
>> directly give you "the match whose match-end is closest" and "the match
>> whose match-end is furthest").
> But that's what we generally want in practice anyway.

Not according to POSIX and not according to the traditional behavior of
Emacs's regexp search.

>> Yes, it's unfortunate.  Maybe we could/should merge them to clarify:
>>      (re-match REGEXP &optional STRING LIMIT START)
>>      (re-search REGEXP &optional STRING LIMIT START)
>> would be like `looking-at` but would operate on STRING instead of
>> `current-buffer` if STRING is non-nil.  START defaults to point for
>> current-buffer and 0 for a string.
> re-search-forward also moves point, whereas string-match returns the index
> of the match start.

Oh, indeed, `re-search-forward` returns the match-end whereas
`string-match` returns the match start.  I hate that difference.

> I'm not sure it's worth the changeover and retraining everybody

Agreed.

> if the main benefit is being more aware of the underlying
> algorithm complexity.

Not sure what this has to do with the algorithm complexity.

> It suppose so. Yet, in all cases I had to rewrite looking-back calls to add
> the now-mandatory argument, the resulting time it took was fast enough to
> get lost in the measurement noise.

Yes, the limit arg hides most of the performance problems, indeed.


        Stefan

Re: Add some aliases for re-related functions

[Philippe Vaucher]

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

> [Again, please consider using plain-text, not HTML, in your messages.]

I try to do that each time, e.g this message should be plain text. Tell me
if it isn't. I reply from gmail and select "remove formatting".

> > You make it sound like because naming is hard
> > bad names are ok
>
> How did I make it sound like that to you?

By systematically showing examples where it's impossible and always
rejecting proposals. Also your tone while your say this kinda imply this is
a futile endeavor. Maybe it's just me misintepretating tho.


> If you look at the particular half-kidding examples
> I showed, you might see that they're not screwball.
> Nearly all of them are perfectly reasonable.  And
> that's the point of showing them.
>
> With a command such as `flush-lines', if we want to
> prefix the name, just what is a good prefix?
>
> Is the command mostly about lines (the type of data
> acted on), so perhaps use prefix `lines-'?
>
> Is it mostly about regexp-matching/searching, so
> perhaps use prefix `re-'?
>
> Is it mostly about deleting text, so perhaps use
> prefix `delete-' (as in one of its aliases)?

First of all let's agree that nobody here proposed to rename flush-lines.

Anyway, if we had to do it I think all your categories are weak IMHO, sure
it touches the concept of lines, regexp and deleting but fundamentally it's
about modifying buffers. If I had to name it it'd be:

keep-lines -> buffer-keep-lines
flush-lines -> buffer-flush-lines

With more finesse I could argue for `buffer-modif-select` and
`buffer-modif-reject` but I'd probably lose you ;-)

Philippe

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

Sending plaintext with Gmail (was: Add some aliases for re-related functions)

[Kévin Le Gouguec]

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

Philippe Vaucher <philippe.vaucher@gmail.com> writes:

>> [Again, please consider using plain-text, not HTML, in your messages.]
>
> I try to do that each time, e.g this message should be plain text. Tell me if it isn't. I reply from gmail and select "remove formatting".

If I am not mistaken, to send plaintext with Gmail, one must open the
"⋮" menu (three vertical dots) and pick "Plain text mode".  "Remove
formatting" merely strips away bold/italic/…, but the outgoing mail is
still HTML.


[-- Attachment #2: gmail-plaintext.png --]
[-- Type: image/png, Size: 27837 bytes --]

[-- Attachment #3: Type: text/plain, Size: 84 bytes --]


Your message is still HTML AFAICT, but it also has a plaintext duplicate
attached.

Re: Sending plaintext with Gmail (was: Add some aliases for re-related functions)

[Philippe Vaucher]

> >> [Again, please consider using plain-text, not HTML, in your messages.]
> >
> > I try to do that each time, e.g this message should be plain text. Tell me if it isn't. I reply from gmail and select "remove formatting".
>
> If I am not mistaken, to send plaintext with Gmail, one must open the
> "⋮" menu (three vertical dots) and pick "Plain text mode".  "Remove
> formatting" merely strips away bold/italic/…, but the outgoing mail is
> still HTML.

Ah, thanks!

Re: Add some aliases for re-related functions

[João Távora]

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

On Sat, May 2, 2020, 22:14 Alan Mackenzie <acm@muc.de> wrote:

> On 1991-07-25, Jim Blandy introduced the alias `search-forward-regexp'
> for `re-search-forward'.  Why?  Lost in the mists of time.  Possibly for
> the same reasons people are advancing now - make all the search functions
> begin with "search-" for supposed easier searching (of their names).  In
> master we currently have 3534 occurences of re-search-forward and 134 of
> search-forward-regexp.  Would anybody here argue that Emacs is the better
> for these 134 alternatively named function calls?  I'd say it was a
> mistake, and there is nothing positive to offset the confusion.


Or `delete-backward-char' and its alias `backward-delete-char'.  We have,
> respectively, 5 and 36 uses.  To me, this is just confusion, whatever the
> original reason was for these aliases.
>
> I say we shouldn't add to such confusion.
>

Very good historic points. I hate these aliases, never know which to pick.
Every second gained in supposed discoverability is crushingly offset later
on by a thousand seconds of second-guessing and doubt over which version to
prefer. It's a really bad deal. Shall I try to be modern, or maintain
consistency with this program? I have plenty of those doubts with much more
important stuff already (iterative/recursive, functional/imperative, etc,
etc) I don't need new ones about naming. What a waste of time.

João

>

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

Re: Add some aliases for re-related functions

[João Távora]

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

On Sun, May 3, 2020, 04:26 Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> > I really cannot wait till you get to renaming
> > functions concerning lines: `line-...' or
> > perhaps `lines-...'.  And their aliases...
>
> I must say I find this mildly offensive.  It's basically a strawman
> argument.
>
> All of us arguing in favor of structuring the namespace have made it
> very clear we have no intention of applying this everywhere.
>

It's rather a (tongue-in-cheek, yes) argument by reduction to absurdity,
which starts most validly from the premise of "consistency" in the opposing
camp.

João

João

>

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

Re: Add some aliases for re-related functions

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: philippe.vaucher@gmail.com, emacs-devel@gnu.org
> Date: Sun, 03 May 2020 23:09:14 -0400
> 
> > "C-h d" doesn't look at the names of the functions.
> 
> Should we change it to look at their names as well as their documentation?
> I have a feeling that would be more useful than the current definition.

I think it would be better to do it the other way around: make "C-h f"
look at the arguments and the first line of the doc string (and
similarly with "C-h v").  "C-h d" is for when you widen the search
because "C-h f" and "C-h a" failed to find something, so conceptually
"C-h d" should be Plan B in many situations.  If we can make Plan A be
more efficient, it will be a net win.  We can also make "C-h d" do the
equivalent of looking at the names by modifying the doc string in
trivial ways (like I did recently for assq and posix-search-forward),
although this is a per-function solution (however, with many doc
strings we already have that for free).

Re: Sending plaintext with Gmail

[Stefan Monnier]

> Your message is still HTML AFAICT, but it also has a plaintext duplicate
> attached.

You can also see it as plain text with an HTML version attached to it ;-)
IOW it seems perfectly fine to me: it's up to your MUA to decide
whether you see the HTML or the plain text version.


        Stefan

Re: Sending plaintext with Gmail

[Kévin Le Gouguec]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Your message is still HTML AFAICT, but it also has a plaintext duplicate
>> attached.
>
> You can also see it as plain text with an HTML version attached to it ;-)

Right; on my setup, Gnus defaults to showing the HTML version, and hides
the plaintext version behind a "[2. text/plain]" button under an
"Attachment" header.

I haven't found an obvious way to prefer the plaintext version in the
Gnus manual 🤔

> IOW it seems perfectly fine to me: it's up to your MUA to decide
> whether you see the HTML or the plain text version.

That does sound sensible.

Re: Sending plaintext with Gmail

[Lars Ingebrigtsen]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> I haven't found an obvious way to prefer the plaintext version in the
> Gnus manual 🤔

See mm-discouraged-alternatives.

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

Re: Sending plaintext with Gmail

[Andreas Schwab]

On Mai 04 2020, Kévin Le Gouguec wrote:

> I haven't found an obvious way to prefer the plaintext version in the
> Gnus manual 🤔

You can add text/html to mm-discouraged-alternatives.  See (emacs-mime)
Display Customization::.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

RE: Add some aliases for re-related functions

[Drew Adams]

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

OK. Perhaps it's just my mail client (Outlook). Thx.

 

> [Again, please consider using plain-text, not HTML, in your messages.]

 

I try to do that each time, e.g this message should be plain text. Tell me if it isn't. I reply from gmail and select "remove formatting".

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

RE: Add some aliases for re-related functions

[Drew Adams]

> > > You make it sound like because naming is hard
> > > bad names are ok
> >
> > How did I make it sound like that to you?
>
> By systematically showing examples where it's
> impossible and always rejecting proposals.
> Also your tone while your say this kinda imply
> this is a futile endeavor. Maybe it's just me
> misintepretating tho.

I'm not in any position to reject anything.
Eli is the maintainer.

I may have disagreed with this or that.
Just one opinion.  Agreement and disagreement,
with accompanying arguments, are normal.

> > If you look at the particular half-kidding examples
> > I showed, you might see that they're not screwball.
> > Nearly all of them are perfectly reasonable.  And
> > that's the point of showing them.
> >
> > With a command such as `flush-lines', if we want to
> > prefix the name, just what is a good prefix?
> >
> > Is the command mostly about lines (the type of data
> > acted on), so perhaps use prefix `lines-'?
> >
> > Is it mostly about regexp-matching/searching, so
> > perhaps use prefix `re-'?
> >
> > Is it mostly about deleting text, so perhaps use
> > prefix `delete-' (as in one of its aliases)?
>
> First of all let's agree that nobody here proposed
> to rename flush-lines.

Fine.

> Anyway, if we had to do it I think all your categories
> are weak IMHO, sure it touches the concept of lines,
> regexp and deleting

I was trying to imagine renamings based on the things
involved, which I thought was what is behind, say,
renaming functions that are, as you said,
"string-related APIs", to have prefix `string-' (and
similarly for regexp-related APIs).

> but fundamentally it's about modifying buffers.

It's about modifying buffer content (only - nothing
else about buffers).  OK.

> If I had to name it it'd be:
>
> keep-lines -> buffer-keep-lines
> flush-lines -> buffer-flush-lines

OK.  So for you the most relevant thing involved
is the buffer.  Can you imagine that some might
think something else is more relevant/helpful?

That's the point (one of the points): which word
to use as prefix - what's the main point/effect
of the function?  What term will users want to
look for first or type first?  (And other
considerations.)

> With more finesse I could argue for
> `buffer-modif-select` and `buffer-modif-reject`
> but I'd probably lose you ;-)

Don't worry about losing me.  I'm not important.
Just try imagining that what's "obvious" to you
might be open to different judgments.  And naming
is very much a judgment call - a balancing act.

Re: Add some aliases for re-related functions

[Dmitry Gutov]

On 04.05.2020 17:28, Eli Zaretskii wrote:
> I think it would be better to do it the other way around: make "C-h f"
> look at the arguments and the first line of the doc string (and
> similarly with "C-h v")

Unusual behavior aside, I don't think our general completion logic will 
work well when input has little correlation to the completion results 
(function names).

Re: Add some aliases for re-related functions

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 4 May 2020 20:12:40 +0300
> 
> On 04.05.2020 17:28, Eli Zaretskii wrote:
> > I think it would be better to do it the other way around: make "C-h f"
> > look at the arguments and the first line of the doc string (and
> > similarly with "C-h v")
> 
> Unusual behavior aside, I don't think our general completion logic will 
> work well when input has little correlation to the completion results 
> (function names).

I don't understand the response: what I wrote had no relation to
completion whatsoever.  Maybe you responded to the wrong message?

Re: Add some aliases for re-related functions

[Dmitry Gutov]

On 04.05.2020 20:35, Eli Zaretskii wrote:
>> Cc:emacs-devel@gnu.org
>> From: Dmitry Gutov<dgutov@yandex.ru>
>> Date: Mon, 4 May 2020 20:12:40 +0300
>>
>> On 04.05.2020 17:28, Eli Zaretskii wrote:
>>> I think it would be better to do it the other way around: make "C-h f"
>>> look at the arguments and the first line of the doc string (and
>>> similarly with "C-h v")
>> Unusual behavior aside, I don't think our general completion logic will
>> work well when input has little correlation to the completion results
>> (function names).
> I don't understand the response: what I wrote had no relation to
> completion whatsoever.  Maybe you responded to the wrong message?

Not at all.

'C-h f' uses completing-read to help the user input the function they'll 
see the description for.

Re: Add some aliases for re-related functions

[Eli Zaretskii]

> Cc: rms@gnu.org, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 4 May 2020 20:42:03 +0300
> 
> On 04.05.2020 20:35, Eli Zaretskii wrote:
> >> Cc:emacs-devel@gnu.org
> >> From: Dmitry Gutov<dgutov@yandex.ru>
> >> Date: Mon, 4 May 2020 20:12:40 +0300
> >>
> >> On 04.05.2020 17:28, Eli Zaretskii wrote:
> >>> I think it would be better to do it the other way around: make "C-h f"
> >>> look at the arguments and the first line of the doc string (and
> >>> similarly with "C-h v")
> >> Unusual behavior aside, I don't think our general completion logic will
> >> work well when input has little correlation to the completion results
> >> (function names).
> > I don't understand the response: what I wrote had no relation to
> > completion whatsoever.  Maybe you responded to the wrong message?
> 
> Not at all.
> 
> 'C-h f' uses completing-read to help the user input the function they'll 
> see the description for.

Yes, but that's entirely unrelated to Richard's question and to my
response.  They had to do with what these command search, not how they
invoke completion of their arguments.

Hmm... I think I see the confusion: I said "C-h f", but had "C-h a" in
mind.  Sorry.

Re: Add some aliases for re-related functions

[Dmitry Gutov]

On 04.05.2020 20:46, Eli Zaretskii wrote:
>> Cc:rms@gnu.org,emacs-devel@gnu.org
>> From: Dmitry Gutov<dgutov@yandex.ru>
>> Date: Mon, 4 May 2020 20:42:03 +0300
>>
>> On 04.05.2020 20:35, Eli Zaretskii wrote:
>>>> Cc:emacs-devel@gnu.org
>>>> From: Dmitry Gutov<dgutov@yandex.ru>
>>>> Date: Mon, 4 May 2020 20:12:40 +0300
>>>>
>>>> On 04.05.2020 17:28, Eli Zaretskii wrote:
>>>>> I think it would be better to do it the other way around: make "C-h f"
>>>>> look at the arguments and the first line of the doc string (and
>>>>> similarly with "C-h v")
>>>> Unusual behavior aside, I don't think our general completion logic will
>>>> work well when input has little correlation to the completion results
>>>> (function names).
>>> I don't understand the response: what I wrote had no relation to
>>> completion whatsoever.  Maybe you responded to the wrong message?
>> Not at all.
>>
>> 'C-h f' uses completing-read to help the user input the function they'll
>> see the description for.
> Yes, but that's entirely unrelated to Richard's question and to my
> response.  They had to do with what these command search, not how they
> invoke completion of their arguments.
> 
> Hmm... I think I see the confusion: I said "C-h f", but had "C-h a" in
> mind.  Sorry.

Hm. You also said "and also C-h v". Which works very much like "C-h f".

But for "C-h a" that can make sense, of course.

Re: Add some aliases for re-related functions

[Philippe Vaucher]

> I may have disagreed with this or that.
> Just one opinion.  Agreement and disagreement,
> with accompanying arguments, are normal.

I probably over reacted a bit, sorry.

> > If I had to name it it'd be:
> >
> > keep-lines -> buffer-keep-lines
> > flush-lines -> buffer-flush-lines
>
> OK.  So for you the most relevant thing involved
> is the buffer.  Can you imagine that some might
> think something else is more relevant/helpful?

But at this point you'd now that I'd be fine with things not being
perfectly categorized.

What I'm complaining about is the lack of categories for a lot of
functions, or categories that don't look consistent. For example, if
everything string-regexp was under the "text-" prefix, I'd already be
pretty happy compared to the current situation. Right now it's a bit
here, a bit there, all spread around.

Also as I said earlier if at least there was a standard, like
"verb-object" I could understand, but the lack of consistency between
"sometimes prefix, sometimes not, sometimes idiosyncracy" makes
everything very unpredictable. Maybe I'd just embrace the chaos and
the uncertainty but, I think having a reasonable amount of arbitrary
prefixes would not be such a crime :-)

Do you see my point?

RE: Add some aliases for re-related functions

[Drew Adams]

> > I may have disagreed with this or that.
> > Just one opinion.  Agreement and disagreement,
> > with accompanying arguments, are normal.
> 
> I probably over reacted a bit, sorry.

It's fine.  I think most of us have been there. ;-)
As someone else said, don't get discouraged.

> But at this point you'd now that I'd be fine with things not being
> perfectly categorized.
> 
> What I'm complaining about is the lack of categories for a lot of
> functions, or categories that don't look consistent. For example, if
> everything string-regexp was under the "text-" prefix, I'd already be
> pretty happy compared to the current situation. Right now it's a bit
> here, a bit there, all spread around.
> 
> Also as I said earlier if at least there was a standard, like
> "verb-object" I could understand, but the lack of consistency between
> "sometimes prefix, sometimes not, sometimes idiosyncracy" makes
> everything very unpredictable. Maybe I'd just embrace the chaos and
> the uncertainty but, I think having a reasonable amount of arbitrary
> prefixes would not be such a crime :-)
> 
> Do you see my point?

I see your point.  We are all lumpers and splitters
to one degree or another, and differently in different
contexts and at different times.  And we can tolerate
inconsistency to different degrees.

Wrt categorizing/naming, as Stefan put it: it's both
hard and impossible.  Still, we try...

Re: Add some aliases for re-related functions

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

  > With a command such as `flush-lines', if we want to
  > prefix the name, just what is a good prefix?

One of the important considerations in many command names, including
'flush-lines', was the ease of specifying it using completion.

Too much prefixing becomes a practical nuisance.

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

HTML display in Gnus (was: Sending plaintext with Gmail)

[Kévin Le Gouguec]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> See mm-discouraged-alternatives.

Andreas Schwab <schwab@linux-m68k.org> writes:

> You can add text/html to mm-discouraged-alternatives.  See (emacs-mime)
> Display Customization::.
>
> Andreas.

Ah, that's where it was!  Thanks :)

I was mostly asking for the sake of people who find HTML unacceptable;
I'm mostly fine with it, though lines spanning the full window width are
somewhat hard to read.

After an hour fiddling with shr-width and gnus-html-frame-width to no
avail, I realized that the latter is only used with the gnus-w3m
renderer, while mm-shr let-binds the former to

(if shr-use-fonts
    nil
  fill-column)

This is surprising (to me), since shr-width's docstring says that an
integer value works just fine even when shr-use-fonts is set:

> If ‘shr-use-fonts’ is set, the mean character width is used to
> compute the pixel width, which is used instead.

I've modified the snippet above to bind shr-width to fill-column
unconditionally, and it works wonders for me.  Maybe this condition
makes no sense anymore?  As things stand, if shr-use-fonts is set, the
user loses control over the line width.

WDYT?

Re: HTML display in Gnus

[Lars Ingebrigtsen]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> After an hour fiddling with shr-width and gnus-html-frame-width to no
> avail, I realized that the latter is only used with the gnus-w3m
> renderer, while mm-shr let-binds the former to
>
> (if shr-use-fonts
>     nil
>   fill-column)
>
> This is surprising (to me), since shr-width's docstring says that an
> integer value works just fine even when shr-use-fonts is set:

Yeah, that looks like a bug, I think...  fill-column should either be
used in both cases or none?

> I've modified the snippet above to bind shr-width to fill-column
> unconditionally, and it works wonders for me.  Maybe this condition
> makes no sense anymore?  As things stand, if shr-use-fonts is set, the
> user loses control over the line width.
>
> WDYT?

The problem is that the user may have a window that's narrower than
fill-column, so I think it may be a misfeature to rely on that variable
in any case.  See bug#40909 -- I think the solution here may be to
introduce a max-width variable for shr instead of having a shr-width
variable.

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

Re: HTML display in Gnus

[Kévin Le Gouguec]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:
>
>> (if shr-use-fonts
>>     nil
>>   fill-column)
>>
>> This is surprising (to me), since shr-width's docstring says that an
>> integer value works just fine even when shr-use-fonts is set:
>
> Yeah, that looks like a bug, I think...  fill-column should either be
> used in both cases or none?

Agreed (and FWIW I'd lean toward both).

> The problem is that the user may have a window that's narrower than
> fill-column, so I think it may be a misfeature to rely on that variable
> in any case.

Right; IIUC that'd make the experience "no worse than" with plaintext
articles hard-wrapped to e.g. 72 columns.  I'd be OK with that, but
that's not an obvious decision to take.

>               See bug#40909 -- I think the solution here may be to
> introduce a max-width variable for shr instead of having a shr-width
> variable.

Wholehearted agreement there!

Re: HTML display in Gnus

[Kévin Le Gouguec]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>               See bug#40909 -- I think the solution here may be to
> introduce a max-width variable for shr instead of having a shr-width
> variable.

Thank you for following up on this! I've just customized shr-max-width
to 72, and HTML emails (and EWW as well) have instantly become much more
readable :)