* Add some aliases for re-related functions @ 2020-05-02 18:28 Yuan Fu 2020-05-02 18:39 ` Eli Zaretskii ` (3 more replies) 0 siblings, 4 replies; 65+ messages in thread From: Yuan Fu @ 2020-05-02 18:28 UTC (permalink / raw) To: Emacs developers 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-02 18:28 Add some aliases for re-related functions Yuan Fu @ 2020-05-02 18:39 ` Eli Zaretskii 2020-05-02 18:43 ` Yuan Fu 2020-05-02 21:21 ` Stefan Monnier 2020-05-02 19:29 ` Alan Mackenzie ` (2 subsequent siblings) 3 siblings, 2 replies; 65+ messages in thread From: Eli Zaretskii @ 2020-05-02 18:39 UTC (permalink / raw) To: Yuan Fu; +Cc: emacs-devel > 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"? ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-02 18:39 ` Eli Zaretskii @ 2020-05-02 18:43 ` Yuan Fu 2020-05-02 21:21 ` Stefan Monnier 1 sibling, 0 replies; 65+ messages in thread From: Yuan Fu @ 2020-05-02 18:43 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-02 18:39 ` Eli Zaretskii 2020-05-02 18:43 ` Yuan Fu @ 2020-05-02 21:21 ` Stefan Monnier 2020-05-02 22:27 ` Drew Adams 1 sibling, 1 reply; 65+ messages in thread From: Stefan Monnier @ 2020-05-02 21:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Yuan Fu, emacs-devel > 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* RE: Add some aliases for re-related functions 2020-05-02 21:21 ` Stefan Monnier @ 2020-05-02 22:27 ` Drew Adams 2020-05-03 8:33 ` Michael Albinus 0 siblings, 1 reply; 65+ messages in thread From: Drew Adams @ 2020-05-02 22:27 UTC (permalink / raw) To: Stefan Monnier, Eli Zaretskii; +Cc: Yuan Fu, emacs-devel > > 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.) ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-02 22:27 ` Drew Adams @ 2020-05-03 8:33 ` Michael Albinus 2020-05-03 19:07 ` Drew Adams 0 siblings, 1 reply; 65+ messages in thread From: Michael Albinus @ 2020-05-03 8:33 UTC (permalink / raw) To: Drew Adams; +Cc: Eli Zaretskii, Yuan Fu, Stefan Monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 65+ messages in thread
* RE: Add some aliases for re-related functions 2020-05-03 8:33 ` Michael Albinus @ 2020-05-03 19:07 ` Drew Adams 0 siblings, 0 replies; 65+ messages in thread From: Drew Adams @ 2020-05-03 19:07 UTC (permalink / raw) To: Michael Albinus; +Cc: Eli Zaretskii, Yuan Fu, Stefan Monnier, emacs-devel > > (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%. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-02 18:28 Add some aliases for re-related functions Yuan Fu 2020-05-02 18:39 ` Eli Zaretskii @ 2020-05-02 19:29 ` Alan Mackenzie 2020-05-02 19:48 ` Yuan Fu 2020-05-02 20:10 ` Philippe Vaucher 2020-05-02 21:33 ` Stefan Monnier 2020-05-04 3:04 ` Richard Stallman 3 siblings, 2 replies; 65+ messages in thread From: Alan Mackenzie @ 2020-05-02 19:29 UTC (permalink / raw) To: Yuan Fu; +Cc: Emacs developers 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). ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-02 19:29 ` Alan Mackenzie @ 2020-05-02 19:48 ` Yuan Fu 2020-05-02 20:10 ` Philippe Vaucher 1 sibling, 0 replies; 65+ messages in thread From: Yuan Fu @ 2020-05-02 19:48 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Emacs developers [-- 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 --] ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-02 19:29 ` Alan Mackenzie 2020-05-02 19:48 ` Yuan Fu @ 2020-05-02 20:10 ` Philippe Vaucher 2020-05-02 20:13 ` Philippe Vaucher ` (2 more replies) 1 sibling, 3 replies; 65+ messages in thread From: Philippe Vaucher @ 2020-05-02 20:10 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Yuan Fu, Emacs developers [-- 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 --] ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-02 20:10 ` Philippe Vaucher @ 2020-05-02 20:13 ` Philippe Vaucher 2020-05-03 14:16 ` Eli Zaretskii 2020-05-02 21:09 ` Alan Mackenzie 2020-05-03 14:16 ` Eli Zaretskii 2 siblings, 1 reply; 65+ messages in thread From: Philippe Vaucher @ 2020-05-02 20:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Emacs developers [-- 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 --] ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-02 20:13 ` Philippe Vaucher @ 2020-05-03 14:16 ` Eli Zaretskii 2020-05-04 3:09 ` Richard Stallman 0 siblings, 1 reply; 65+ messages in thread From: Eli Zaretskii @ 2020-05-03 14:16 UTC (permalink / raw) To: Philippe Vaucher; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-03 14:16 ` Eli Zaretskii @ 2020-05-04 3:09 ` Richard Stallman 2020-05-04 14:28 ` Eli Zaretskii 0 siblings, 1 reply; 65+ messages in thread From: Richard Stallman @ 2020-05-04 3:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-04 3:09 ` Richard Stallman @ 2020-05-04 14:28 ` Eli Zaretskii 2020-05-04 17:12 ` Dmitry Gutov 0 siblings, 1 reply; 65+ messages in thread From: Eli Zaretskii @ 2020-05-04 14:28 UTC (permalink / raw) To: rms; +Cc: emacs-devel > 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). ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-04 14:28 ` Eli Zaretskii @ 2020-05-04 17:12 ` Dmitry Gutov 2020-05-04 17:35 ` Eli Zaretskii 0 siblings, 1 reply; 65+ messages in thread From: Dmitry Gutov @ 2020-05-04 17:12 UTC (permalink / raw) To: Eli Zaretskii, rms; +Cc: emacs-devel 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). ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-04 17:12 ` Dmitry Gutov @ 2020-05-04 17:35 ` Eli Zaretskii 2020-05-04 17:42 ` Dmitry Gutov 0 siblings, 1 reply; 65+ messages in thread From: Eli Zaretskii @ 2020-05-04 17:35 UTC (permalink / raw) To: Dmitry Gutov; +Cc: rms, emacs-devel > 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? ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-04 17:35 ` Eli Zaretskii @ 2020-05-04 17:42 ` Dmitry Gutov 2020-05-04 17:46 ` Eli Zaretskii 0 siblings, 1 reply; 65+ messages in thread From: Dmitry Gutov @ 2020-05-04 17:42 UTC (permalink / raw) To: Eli Zaretskii; +Cc: rms, emacs-devel 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. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-04 17:42 ` Dmitry Gutov @ 2020-05-04 17:46 ` Eli Zaretskii 2020-05-04 17:53 ` Dmitry Gutov 0 siblings, 1 reply; 65+ messages in thread From: Eli Zaretskii @ 2020-05-04 17:46 UTC (permalink / raw) To: Dmitry Gutov; +Cc: rms, emacs-devel > 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. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-04 17:46 ` Eli Zaretskii @ 2020-05-04 17:53 ` Dmitry Gutov 0 siblings, 0 replies; 65+ messages in thread From: Dmitry Gutov @ 2020-05-04 17:53 UTC (permalink / raw) To: Eli Zaretskii; +Cc: rms, emacs-devel 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. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-02 20:10 ` Philippe Vaucher 2020-05-02 20:13 ` Philippe Vaucher @ 2020-05-02 21:09 ` Alan Mackenzie 2020-05-02 21:51 ` Philippe Vaucher ` (2 more replies) 2020-05-03 14:16 ` Eli Zaretskii 2 siblings, 3 replies; 65+ messages in thread From: Alan Mackenzie @ 2020-05-02 21:09 UTC (permalink / raw) To: Philippe Vaucher; +Cc: Yuan Fu, Emacs developers 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). ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-02 21:09 ` Alan Mackenzie @ 2020-05-02 21:51 ` Philippe Vaucher 2020-05-03 9:43 ` Alan Mackenzie 2020-05-02 22:41 ` Stefan Monnier 2020-05-04 10:07 ` João Távora 2 siblings, 1 reply; 65+ messages in thread From: Philippe Vaucher @ 2020-05-02 21:51 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Yuan Fu, Emacs developers [-- 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 --] ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-02 21:51 ` Philippe Vaucher @ 2020-05-03 9:43 ` Alan Mackenzie 2020-05-03 15:00 ` 조성빈 0 siblings, 1 reply; 65+ messages in thread From: Alan Mackenzie @ 2020-05-03 9:43 UTC (permalink / raw) To: Philippe Vaucher; +Cc: Yuan Fu, Emacs developers 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). ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-03 9:43 ` Alan Mackenzie @ 2020-05-03 15:00 ` 조성빈 0 siblings, 0 replies; 65+ messages in thread From: 조성빈 @ 2020-05-03 15:00 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Philippe Vaucher, Yuan Fu, Emacs developers 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’. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-02 21:09 ` Alan Mackenzie 2020-05-02 21:51 ` Philippe Vaucher @ 2020-05-02 22:41 ` Stefan Monnier 2020-05-03 17:14 ` Alan Mackenzie 2020-05-04 10:07 ` João Távora 2 siblings, 1 reply; 65+ messages in thread From: Stefan Monnier @ 2020-05-02 22:41 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Yuan Fu, Emacs developers > 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-02 22:41 ` Stefan Monnier @ 2020-05-03 17:14 ` Alan Mackenzie 0 siblings, 0 replies; 65+ messages in thread From: Alan Mackenzie @ 2020-05-03 17:14 UTC (permalink / raw) To: Stefan Monnier; +Cc: Yuan Fu, Emacs developers 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). ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-02 21:09 ` Alan Mackenzie 2020-05-02 21:51 ` Philippe Vaucher 2020-05-02 22:41 ` Stefan Monnier @ 2020-05-04 10:07 ` João Távora 2 siblings, 0 replies; 65+ messages in thread From: João Távora @ 2020-05-04 10:07 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Yuan Fu, Emacs developers [-- 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 --] ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-02 20:10 ` Philippe Vaucher 2020-05-02 20:13 ` Philippe Vaucher 2020-05-02 21:09 ` Alan Mackenzie @ 2020-05-03 14:16 ` Eli Zaretskii 2020-05-03 16:20 ` Yuri Khan 2 siblings, 1 reply; 65+ messages in thread From: Eli Zaretskii @ 2020-05-03 14:16 UTC (permalink / raw) To: Philippe Vaucher; +Cc: acm, casouri, emacs-devel > 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. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-03 14:16 ` Eli Zaretskii @ 2020-05-03 16:20 ` Yuri Khan 2020-05-03 16:42 ` Eli Zaretskii 0 siblings, 1 reply; 65+ messages in thread From: Yuri Khan @ 2020-05-03 16:20 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Alan Mackenzie, Yuan Fu, Emacs developers 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).” ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-03 16:20 ` Yuri Khan @ 2020-05-03 16:42 ` Eli Zaretskii 2020-05-03 16:50 ` Dmitry Gutov 0 siblings, 1 reply; 65+ messages in thread From: Eli Zaretskii @ 2020-05-03 16:42 UTC (permalink / raw) To: Yuri Khan; +Cc: acm, casouri, emacs-devel > 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. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-03 16:42 ` Eli Zaretskii @ 2020-05-03 16:50 ` Dmitry Gutov 0 siblings, 0 replies; 65+ messages in thread From: Dmitry Gutov @ 2020-05-03 16:50 UTC (permalink / raw) To: Eli Zaretskii, Yuri Khan; +Cc: acm, casouri, emacs-devel 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. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-02 18:28 Add some aliases for re-related functions Yuan Fu 2020-05-02 18:39 ` Eli Zaretskii 2020-05-02 19:29 ` Alan Mackenzie @ 2020-05-02 21:33 ` Stefan Monnier 2020-05-02 22:10 ` Dmitry Gutov 2020-05-02 22:44 ` Drew Adams 2020-05-04 3:04 ` Richard Stallman 3 siblings, 2 replies; 65+ messages in thread From: Stefan Monnier @ 2020-05-02 21:33 UTC (permalink / raw) To: Yuan Fu; +Cc: Emacs developers > 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-02 21:33 ` Stefan Monnier @ 2020-05-02 22:10 ` Dmitry Gutov 2020-05-02 22:18 ` Eric Abrahamsen 2020-05-02 22:49 ` Stefan Monnier 2020-05-02 22:44 ` Drew Adams 1 sibling, 2 replies; 65+ messages in thread From: Dmitry Gutov @ 2020-05-02 22:10 UTC (permalink / raw) To: Stefan Monnier, Yuan Fu; +Cc: Emacs developers 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. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-02 22:10 ` Dmitry Gutov @ 2020-05-02 22:18 ` Eric Abrahamsen 2020-05-02 22:49 ` Stefan Monnier 1 sibling, 0 replies; 65+ messages in thread From: Eric Abrahamsen @ 2020-05-02 22:18 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Yuan Fu, Stefan Monnier, Emacs developers 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¢... ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-02 22:10 ` Dmitry Gutov 2020-05-02 22:18 ` Eric Abrahamsen @ 2020-05-02 22:49 ` Stefan Monnier 2020-05-02 23:13 ` Dmitry Gutov 1 sibling, 1 reply; 65+ messages in thread From: Stefan Monnier @ 2020-05-02 22:49 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Yuan Fu, Emacs developers >> [ 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. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-02 22:49 ` Stefan Monnier @ 2020-05-02 23:13 ` Dmitry Gutov 2020-05-03 3:55 ` Stefan Monnier 0 siblings, 1 reply; 65+ messages in thread From: Dmitry Gutov @ 2020-05-02 23:13 UTC (permalink / raw) To: Stefan Monnier; +Cc: Yuan Fu, Emacs developers 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. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-02 23:13 ` Dmitry Gutov @ 2020-05-03 3:55 ` Stefan Monnier 2020-05-04 0:29 ` Dmitry Gutov 0 siblings, 1 reply; 65+ messages in thread From: Stefan Monnier @ 2020-05-03 3:55 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Yuan Fu, Emacs developers >> 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-03 3:55 ` Stefan Monnier @ 2020-05-04 0:29 ` Dmitry Gutov 2020-05-04 3:11 ` Stefan Monnier 0 siblings, 1 reply; 65+ messages in thread From: Dmitry Gutov @ 2020-05-04 0:29 UTC (permalink / raw) To: Stefan Monnier; +Cc: Yuan Fu, Emacs developers 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. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-04 0:29 ` Dmitry Gutov @ 2020-05-04 3:11 ` Stefan Monnier 0 siblings, 0 replies; 65+ messages in thread From: Stefan Monnier @ 2020-05-04 3:11 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Yuan Fu, Emacs developers >> 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* RE: Add some aliases for re-related functions 2020-05-02 21:33 ` Stefan Monnier 2020-05-02 22:10 ` Dmitry Gutov @ 2020-05-02 22:44 ` Drew Adams 2020-05-03 3:26 ` Stefan Monnier 1 sibling, 1 reply; 65+ messages in thread From: Drew Adams @ 2020-05-02 22:44 UTC (permalink / raw) To: Stefan Monnier, Yuan Fu; +Cc: Emacs developers > > 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? ;-) ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-02 22:44 ` Drew Adams @ 2020-05-03 3:26 ` Stefan Monnier 2020-05-03 4:37 ` Drew Adams 2020-05-04 10:16 ` João Távora 0 siblings, 2 replies; 65+ messages in thread From: Stefan Monnier @ 2020-05-03 3:26 UTC (permalink / raw) To: Drew Adams; +Cc: Yuan Fu, Emacs developers > 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* RE: Add some aliases for re-related functions 2020-05-03 3:26 ` Stefan Monnier @ 2020-05-03 4:37 ` Drew Adams 2020-05-03 8:05 ` Philippe Vaucher 2020-05-04 3:08 ` Richard Stallman 2020-05-04 10:16 ` João Távora 1 sibling, 2 replies; 65+ messages in thread From: Drew Adams @ 2020-05-03 4:37 UTC (permalink / raw) To: Stefan Monnier; +Cc: Yuan Fu, Emacs developers > > 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. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-03 4:37 ` Drew Adams @ 2020-05-03 8:05 ` Philippe Vaucher 2020-05-03 9:55 ` Alan Mackenzie 2020-05-03 19:47 ` Drew Adams 2020-05-04 3:08 ` Richard Stallman 1 sibling, 2 replies; 65+ messages in thread From: Philippe Vaucher @ 2020-05-03 8:05 UTC (permalink / raw) To: Drew Adams; +Cc: Yuan Fu, Stefan Monnier, Emacs developers [-- 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 --] ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-03 8:05 ` Philippe Vaucher @ 2020-05-03 9:55 ` Alan Mackenzie 2020-05-03 10:26 ` tomas 2020-05-03 15:15 ` Eli Zaretskii 2020-05-03 19:47 ` Drew Adams 1 sibling, 2 replies; 65+ messages in thread From: Alan Mackenzie @ 2020-05-03 9:55 UTC (permalink / raw) To: Philippe Vaucher; +Cc: Yuan Fu, Stefan Monnier, Drew Adams, Emacs developers 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). ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-03 9:55 ` Alan Mackenzie @ 2020-05-03 10:26 ` tomas 2020-05-03 15:15 ` Eli Zaretskii 1 sibling, 0 replies; 65+ messages in thread From: tomas @ 2020-05-03 10:26 UTC (permalink / raw) To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-03 9:55 ` Alan Mackenzie 2020-05-03 10:26 ` tomas @ 2020-05-03 15:15 ` Eli Zaretskii 1 sibling, 0 replies; 65+ messages in thread From: Eli Zaretskii @ 2020-05-03 15:15 UTC (permalink / raw) To: Alan Mackenzie; +Cc: emacs-devel, casouri, drew.adams, monnier > 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. ^ permalink raw reply [flat|nested] 65+ messages in thread
* RE: Add some aliases for re-related functions 2020-05-03 8:05 ` Philippe Vaucher 2020-05-03 9:55 ` Alan Mackenzie @ 2020-05-03 19:47 ` Drew Adams 2020-05-04 7:32 ` Philippe Vaucher 2020-05-05 2:48 ` Richard Stallman 1 sibling, 2 replies; 65+ messages in thread From: Drew Adams @ 2020-05-03 19:47 UTC (permalink / raw) To: Philippe Vaucher; +Cc: Yuan Fu, Stefan Monnier, Emacs developers [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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-03 19:47 ` Drew Adams @ 2020-05-04 7:32 ` Philippe Vaucher 2020-05-04 8:20 ` Sending plaintext with Gmail (was: Add some aliases for re-related functions) Kévin Le Gouguec ` (2 more replies) 2020-05-05 2:48 ` Richard Stallman 1 sibling, 3 replies; 65+ messages in thread From: Philippe Vaucher @ 2020-05-04 7:32 UTC (permalink / raw) To: Drew Adams; +Cc: Yuan Fu, Stefan Monnier, Emacs developers [-- 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 --] ^ permalink raw reply [flat|nested] 65+ messages in thread
* Sending plaintext with Gmail (was: Add some aliases for re-related functions) 2020-05-04 7:32 ` Philippe Vaucher @ 2020-05-04 8:20 ` Kévin Le Gouguec 2020-05-04 8:45 ` Philippe Vaucher 2020-05-04 15:09 ` Sending plaintext with Gmail Stefan Monnier 2020-05-04 16:51 ` Add some aliases for re-related functions Drew Adams 2020-05-04 17:10 ` Drew Adams 2 siblings, 2 replies; 65+ messages in thread From: Kévin Le Gouguec @ 2020-05-04 8:20 UTC (permalink / raw) To: Philippe Vaucher; +Cc: Yuan Fu, Stefan Monnier, Drew Adams, Emacs developers [-- 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. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Sending plaintext with Gmail (was: Add some aliases for re-related functions) 2020-05-04 8:20 ` Sending plaintext with Gmail (was: Add some aliases for re-related functions) Kévin Le Gouguec @ 2020-05-04 8:45 ` Philippe Vaucher 2020-05-04 15:09 ` Sending plaintext with Gmail Stefan Monnier 1 sibling, 0 replies; 65+ messages in thread From: Philippe Vaucher @ 2020-05-04 8:45 UTC (permalink / raw) To: Kévin Le Gouguec Cc: Yuan Fu, Stefan Monnier, Drew Adams, Emacs developers > >> [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! ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Sending plaintext with Gmail 2020-05-04 8:20 ` Sending plaintext with Gmail (was: Add some aliases for re-related functions) Kévin Le Gouguec 2020-05-04 8:45 ` Philippe Vaucher @ 2020-05-04 15:09 ` Stefan Monnier 2020-05-04 15:25 ` Kévin Le Gouguec 1 sibling, 1 reply; 65+ messages in thread From: Stefan Monnier @ 2020-05-04 15:09 UTC (permalink / raw) To: Kévin Le Gouguec; +Cc: Yuan Fu, Drew Adams, Emacs developers > 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Sending plaintext with Gmail 2020-05-04 15:09 ` Sending plaintext with Gmail Stefan Monnier @ 2020-05-04 15:25 ` Kévin Le Gouguec 2020-05-04 15:29 ` Lars Ingebrigtsen 2020-05-04 15:39 ` Sending plaintext with Gmail Andreas Schwab 0 siblings, 2 replies; 65+ messages in thread From: Kévin Le Gouguec @ 2020-05-04 15:25 UTC (permalink / raw) To: Stefan Monnier; +Cc: Yuan Fu, Drew Adams, Emacs developers 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. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Sending plaintext with Gmail 2020-05-04 15:25 ` Kévin Le Gouguec @ 2020-05-04 15:29 ` Lars Ingebrigtsen 2020-05-05 8:13 ` HTML display in Gnus (was: Sending plaintext with Gmail) Kévin Le Gouguec 2020-05-04 15:39 ` Sending plaintext with Gmail Andreas Schwab 1 sibling, 1 reply; 65+ messages in thread From: Lars Ingebrigtsen @ 2020-05-04 15:29 UTC (permalink / raw) To: Kévin Le Gouguec Cc: Yuan Fu, Stefan Monnier, Drew Adams, Emacs developers 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* HTML display in Gnus (was: Sending plaintext with Gmail) 2020-05-04 15:29 ` Lars Ingebrigtsen @ 2020-05-05 8:13 ` Kévin Le Gouguec 2020-05-05 8:24 ` HTML display in Gnus Lars Ingebrigtsen 0 siblings, 1 reply; 65+ messages in thread From: Kévin Le Gouguec @ 2020-05-05 8:13 UTC (permalink / raw) To: Lars Ingebrigtsen, Andreas Schwab; +Cc: Emacs developers 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? ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: HTML display in Gnus 2020-05-05 8:13 ` HTML display in Gnus (was: Sending plaintext with Gmail) Kévin Le Gouguec @ 2020-05-05 8:24 ` Lars Ingebrigtsen 2020-05-05 9:26 ` Kévin Le Gouguec 2020-07-17 17:14 ` Kévin Le Gouguec 0 siblings, 2 replies; 65+ messages in thread From: Lars Ingebrigtsen @ 2020-05-05 8:24 UTC (permalink / raw) To: Kévin Le Gouguec; +Cc: Andreas Schwab, Emacs developers 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 ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: HTML display in Gnus 2020-05-05 8:24 ` HTML display in Gnus Lars Ingebrigtsen @ 2020-05-05 9:26 ` Kévin Le Gouguec 2020-07-17 17:14 ` Kévin Le Gouguec 1 sibling, 0 replies; 65+ messages in thread From: Kévin Le Gouguec @ 2020-05-05 9:26 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Andreas Schwab, Emacs developers 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! ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: HTML display in Gnus 2020-05-05 8:24 ` HTML display in Gnus Lars Ingebrigtsen 2020-05-05 9:26 ` Kévin Le Gouguec @ 2020-07-17 17:14 ` Kévin Le Gouguec 1 sibling, 0 replies; 65+ messages in thread From: Kévin Le Gouguec @ 2020-07-17 17:14 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Andreas Schwab, Emacs developers 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 :) ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Sending plaintext with Gmail 2020-05-04 15:25 ` Kévin Le Gouguec 2020-05-04 15:29 ` Lars Ingebrigtsen @ 2020-05-04 15:39 ` Andreas Schwab 1 sibling, 0 replies; 65+ messages in thread From: Andreas Schwab @ 2020-05-04 15:39 UTC (permalink / raw) To: Kévin Le Gouguec Cc: Yuan Fu, Stefan Monnier, Drew Adams, Emacs developers 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." ^ permalink raw reply [flat|nested] 65+ messages in thread
* RE: Add some aliases for re-related functions 2020-05-04 7:32 ` Philippe Vaucher 2020-05-04 8:20 ` Sending plaintext with Gmail (was: Add some aliases for re-related functions) Kévin Le Gouguec @ 2020-05-04 16:51 ` Drew Adams 2020-05-04 17:10 ` Drew Adams 2 siblings, 0 replies; 65+ messages in thread From: Drew Adams @ 2020-05-04 16:51 UTC (permalink / raw) To: Philippe Vaucher; +Cc: Yuan Fu, Stefan Monnier, Emacs developers [-- 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 --] ^ permalink raw reply [flat|nested] 65+ messages in thread
* RE: Add some aliases for re-related functions 2020-05-04 7:32 ` Philippe Vaucher 2020-05-04 8:20 ` Sending plaintext with Gmail (was: Add some aliases for re-related functions) Kévin Le Gouguec 2020-05-04 16:51 ` Add some aliases for re-related functions Drew Adams @ 2020-05-04 17:10 ` Drew Adams 2020-05-04 18:17 ` Philippe Vaucher 2 siblings, 1 reply; 65+ messages in thread From: Drew Adams @ 2020-05-04 17:10 UTC (permalink / raw) To: Philippe Vaucher; +Cc: Yuan Fu, Stefan Monnier, Emacs developers > > > 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. ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-04 17:10 ` Drew Adams @ 2020-05-04 18:17 ` Philippe Vaucher 2020-05-04 18:33 ` Drew Adams 0 siblings, 1 reply; 65+ messages in thread From: Philippe Vaucher @ 2020-05-04 18:17 UTC (permalink / raw) To: Drew Adams; +Cc: Yuan Fu, Stefan Monnier, Emacs developers > 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? ^ permalink raw reply [flat|nested] 65+ messages in thread
* RE: Add some aliases for re-related functions 2020-05-04 18:17 ` Philippe Vaucher @ 2020-05-04 18:33 ` Drew Adams 0 siblings, 0 replies; 65+ messages in thread From: Drew Adams @ 2020-05-04 18:33 UTC (permalink / raw) To: Philippe Vaucher; +Cc: Yuan Fu, Stefan Monnier, Emacs developers > > 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... ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-03 19:47 ` Drew Adams 2020-05-04 7:32 ` Philippe Vaucher @ 2020-05-05 2:48 ` Richard Stallman 1 sibling, 0 replies; 65+ messages in thread From: Richard Stallman @ 2020-05-05 2:48 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel, casouri, monnier [[[ 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) ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-03 4:37 ` Drew Adams 2020-05-03 8:05 ` Philippe Vaucher @ 2020-05-04 3:08 ` Richard Stallman 1 sibling, 0 replies; 65+ messages in thread From: Richard Stallman @ 2020-05-04 3:08 UTC (permalink / raw) To: Drew Adams; +Cc: casouri, monnier, emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-03 3:26 ` Stefan Monnier 2020-05-03 4:37 ` Drew Adams @ 2020-05-04 10:16 ` João Távora 1 sibling, 0 replies; 65+ messages in thread From: João Távora @ 2020-05-04 10:16 UTC (permalink / raw) To: Stefan Monnier; +Cc: Yuan Fu, Drew Adams, Emacs developers [-- 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 --] ^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: Add some aliases for re-related functions 2020-05-02 18:28 Add some aliases for re-related functions Yuan Fu ` (2 preceding siblings ...) 2020-05-02 21:33 ` Stefan Monnier @ 2020-05-04 3:04 ` Richard Stallman 3 siblings, 0 replies; 65+ messages in thread From: Richard Stallman @ 2020-05-04 3:04 UTC (permalink / raw) To: Yuan Fu; +Cc: emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 65+ messages in thread
end of thread, other threads:[~2020-07-17 17:14 UTC | newest] Thread overview: 65+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-05-02 18:28 Add some aliases for re-related functions Yuan Fu 2020-05-02 18:39 ` Eli Zaretskii 2020-05-02 18:43 ` Yuan Fu 2020-05-02 21:21 ` Stefan Monnier 2020-05-02 22:27 ` Drew Adams 2020-05-03 8:33 ` Michael Albinus 2020-05-03 19:07 ` Drew Adams 2020-05-02 19:29 ` Alan Mackenzie 2020-05-02 19:48 ` Yuan Fu 2020-05-02 20:10 ` Philippe Vaucher 2020-05-02 20:13 ` Philippe Vaucher 2020-05-03 14:16 ` Eli Zaretskii 2020-05-04 3:09 ` Richard Stallman 2020-05-04 14:28 ` Eli Zaretskii 2020-05-04 17:12 ` Dmitry Gutov 2020-05-04 17:35 ` Eli Zaretskii 2020-05-04 17:42 ` Dmitry Gutov 2020-05-04 17:46 ` Eli Zaretskii 2020-05-04 17:53 ` Dmitry Gutov 2020-05-02 21:09 ` Alan Mackenzie 2020-05-02 21:51 ` Philippe Vaucher 2020-05-03 9:43 ` Alan Mackenzie 2020-05-03 15:00 ` 조성빈 2020-05-02 22:41 ` Stefan Monnier 2020-05-03 17:14 ` Alan Mackenzie 2020-05-04 10:07 ` João Távora 2020-05-03 14:16 ` Eli Zaretskii 2020-05-03 16:20 ` Yuri Khan 2020-05-03 16:42 ` Eli Zaretskii 2020-05-03 16:50 ` Dmitry Gutov 2020-05-02 21:33 ` Stefan Monnier 2020-05-02 22:10 ` Dmitry Gutov 2020-05-02 22:18 ` Eric Abrahamsen 2020-05-02 22:49 ` Stefan Monnier 2020-05-02 23:13 ` Dmitry Gutov 2020-05-03 3:55 ` Stefan Monnier 2020-05-04 0:29 ` Dmitry Gutov 2020-05-04 3:11 ` Stefan Monnier 2020-05-02 22:44 ` Drew Adams 2020-05-03 3:26 ` Stefan Monnier 2020-05-03 4:37 ` Drew Adams 2020-05-03 8:05 ` Philippe Vaucher 2020-05-03 9:55 ` Alan Mackenzie 2020-05-03 10:26 ` tomas 2020-05-03 15:15 ` Eli Zaretskii 2020-05-03 19:47 ` Drew Adams 2020-05-04 7:32 ` Philippe Vaucher 2020-05-04 8:20 ` Sending plaintext with Gmail (was: Add some aliases for re-related functions) Kévin Le Gouguec 2020-05-04 8:45 ` Philippe Vaucher 2020-05-04 15:09 ` Sending plaintext with Gmail Stefan Monnier 2020-05-04 15:25 ` Kévin Le Gouguec 2020-05-04 15:29 ` Lars Ingebrigtsen 2020-05-05 8:13 ` HTML display in Gnus (was: Sending plaintext with Gmail) Kévin Le Gouguec 2020-05-05 8:24 ` HTML display in Gnus Lars Ingebrigtsen 2020-05-05 9:26 ` Kévin Le Gouguec 2020-07-17 17:14 ` Kévin Le Gouguec 2020-05-04 15:39 ` Sending plaintext with Gmail Andreas Schwab 2020-05-04 16:51 ` Add some aliases for re-related functions Drew Adams 2020-05-04 17:10 ` Drew Adams 2020-05-04 18:17 ` Philippe Vaucher 2020-05-04 18:33 ` Drew Adams 2020-05-05 2:48 ` Richard Stallman 2020-05-04 3:08 ` Richard Stallman 2020-05-04 10:16 ` João Távora 2020-05-04 3:04 ` Richard Stallman
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).