How to test if the current line contains only white-spache?

How to test if the current line contains only white-spache?

[Rolf Ade]

For some random minor elisp code I need to know, if the current line
contains only white-space characters[1].

I came up with this somewhat convoluted code:

(beginning-of-line)
(skip-chars-forward " \t")
(let ((text-start (current-column)))
  (end-of-line)
  (if (= text-start (current-column))
      t
    nil)

(and that is, obviously, without saving point position and wrapping
into and a defun and maybe other bells and whistles).

I wonder, what much simpler and more elegant solution I'm missing.

rolf


[1] "White-space characters" in this sense atm defines to just " " and
"\t". Lets accept that for the context of the question, I know there are
other definitions of white-space characters.

Re: How to test if the current line contains only white-spache?

[Barry Margolin]

In article <87r3js7e8l.fsf@linux-qg7d.fritz.box>,
 Rolf Ade <rolf@pointsman.de> wrote:

> For some random minor elisp code I need to know, if the current line
> contains only white-space characters[1].
> 
> I came up with this somewhat convoluted code:
> 
> (beginning-of-line)
> (skip-chars-forward " \t")
> (let ((text-start (current-column)))
>   (end-of-line)
>   (if (= text-start (current-column))
>       t
>     nil)
> 
> (and that is, obviously, without saving point position and wrapping
> into and a defun and maybe other bells and whistles).
> 
> I wonder, what much simpler and more elegant solution I'm missing.

(save-excursion
  (beginning-of-line)
  (looking-at "[ \t]*$"))

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: How to test if the current line contains only white-spache?

[Yuri Khan]

On Sat, Nov 14, 2015 at 10:11 PM, Rolf Ade <rolf@pointsman.de> wrote:

> For some random minor elisp code I need to know, if the current line
> contains only white-space characters[1].
>
> I came up with this somewhat convoluted code: […]
> I wonder, what much simpler and more elegant solution I'm missing.

(beginning-of-line)
(if (looking-at "[ \t]*\n")
    …
  …)

Re: How to test if the current line contains only white-spache?

[John Mastro]

> For some random minor elisp code I need to know, if the current line
> contains only white-space characters[1].
> 
> I came up with this somewhat convoluted code:
> 
> (beginning-of-line)
> (skip-chars-forward " \t")
> (let ((text-start (current-column)))
>  (end-of-line)
>  (if (= text-start (current-column))
>      t
>    nil)
> 
> (and that is, obviously, without saving point position and wrapping
> into and a defun and maybe other bells and whistles).
> 
> I wonder, what much simpler and more elegant solution I'm missing.

An alternative would be to use a regexp.

Here's an (untested, typed-on-mobile) example:

(beginning-of-line)
(looking-at-p "^[ \t]*$")

-- 
john

Re: How to test if the current line contains only white-spache?

[Marcin Borkowski]

On 2015-11-14, at 19:42, Barry Margolin <barmar@alum.mit.edu> wrote:

> In article <87r3js7e8l.fsf@linux-qg7d.fritz.box>,
>  Rolf Ade <rolf@pointsman.de> wrote:
>
>> For some random minor elisp code I need to know, if the current line
>> contains only white-space characters[1].
>> 
>> I came up with this somewhat convoluted code:
>> 
>> (beginning-of-line)
>> (skip-chars-forward " \t")
>> (let ((text-start (current-column)))
>>   (end-of-line)
>>   (if (= text-start (current-column))
>>       t
>>     nil)
>> 
>> (and that is, obviously, without saving point position and wrapping
>> into and a defun and maybe other bells and whistles).
>> 
>> I wonder, what much simpler and more elegant solution I'm missing.
>
> (save-excursion
>   (beginning-of-line)
>   (looking-at "[ \t]*$"))

You might also (depending on your use-case) want to use looking-at-p,
which is marginally slower than looking-at, but does not modify match
data.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: How to test if the current line contains only white-spache?

[Rolf Ade]

Barry Margolin <barmar@alum.mit.edu> writes:
>  Rolf Ade <rolf@pointsman.de> wrote:
>
>> For some random minor elisp code I need to know, if the current line
>> contains only white-space characters[1].
>> 
>> I came up with this somewhat convoluted code:
>> 
>> (beginning-of-line)
>> (skip-chars-forward " \t")
>> (let ((text-start (current-column)))
>>   (end-of-line)
>>   (if (= text-start (current-column))
>>       t
>>     nil)
>> 
>> (and that is, obviously, without saving point position and wrapping
>> into and a defun and maybe other bells and whistles).
>> 
>> I wonder, what much simpler and more elegant solution I'm missing.
>
> (save-excursion
>   (beginning-of-line)
>   (looking-at "[ \t]*$"))

Works fine and is much simpler. Thanks.

Re: How to test if the current line contains only white-spache?

[Philipp Stephani]

Marcin Borkowski <mbork@mbork.pl> schrieb am Mo., 16. Nov. 2015 um
08:10 Uhr:

>
> On 2015-11-14, at 19:42, Barry Margolin <barmar@alum.mit.edu> wrote:
>
> > In article <87r3js7e8l.fsf@linux-qg7d.fritz.box>,
> >  Rolf Ade <rolf@pointsman.de> wrote:
> >
> >> For some random minor elisp code I need to know, if the current line
> >> contains only white-space characters[1].
> >>
> >> I came up with this somewhat convoluted code:
> >>
> >> (beginning-of-line)
> >> (skip-chars-forward " \t")
> >> (let ((text-start (current-column)))
> >>   (end-of-line)
> >>   (if (= text-start (current-column))
> >>       t
> >>     nil)
> >>
> >> (and that is, obviously, without saving point position and wrapping
> >> into and a defun and maybe other bells and whistles).
> >>
> >> I wonder, what much simpler and more elegant solution I'm missing.
> >
> > (save-excursion
> >   (beginning-of-line)
> >   (looking-at "[ \t]*$"))
>
> You might also (depending on your use-case) want to use looking-at-p,
> which is marginally slower than looking-at, but does not modify match
> data.
>

Another small improvement: Use the regex "[[:space:]]*$" or (rx (* space)
eol) to respect the definition of whitespace in the current syntax table.

Re: How to test if the current line contains only white-spache?

[Emanuel Berg]

Rolf Ade <rolf@pointsman.de> writes:

> Works fine and is much simpler. Thanks.

Here is another solution that is all C, and doesn't
move point. Is that an advantage? ... (Open question.)

(defun blank-line ()
  (interactive)
  (message (if
               (string-match "^[[:space:]]*$"
                             (buffer-substring-no-properties
                              (line-beginning-position)
                              (line-end-position) )) "blank" "not so") ))

Non-interactive use could be:

(defun blank-line-p ()
  (string-match "^[[:space:]]*$"
                (buffer-substring-no-properties
                 (line-beginning-position)
                 (line-end-position) )))

(blank-line-p) ; nil

(progn (previous-line 2)
       (blank-line-p) ) ; 0, i.e. non-nil - (when 0   t) => t
                        ;                   (when nil t) => nil

Keep it up!

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: How to test if the current line contains only white-spache?

[Marcin Borkowski]

On 2015-11-17, at 01:26, Emanuel Berg <embe8573@student.uu.se> wrote:

> Rolf Ade <rolf@pointsman.de> writes:
>
>> Works fine and is much simpler. Thanks.
>
> Here is another solution that is all C, and doesn't
> move point. Is that an advantage? ... (Open question.)
>
> (defun blank-line ()
>   (interactive)
>   (message (if
>                (string-match "^[[:space:]]*$"
>                              (buffer-substring-no-properties
>                               (line-beginning-position)
>                               (line-end-position) )) "blank" "not so") ))
>
> Non-interactive use could be:
>
> (defun blank-line-p ()
>   (string-match "^[[:space:]]*$"
>                 (buffer-substring-no-properties
>                  (line-beginning-position)
>                  (line-end-position) )))
>
> (blank-line-p) ; nil
>
> (progn (previous-line 2)
>        (blank-line-p) ) ; 0, i.e. non-nil - (when 0   t) => t
>                         ;                   (when nil t) => nil
>
> Keep it up!

I would be a bit afraid about performance if using this idea many
times.  Using strings /might/ cause GC to run more often.

Some time ago I wrote a small template mechanism for Emacs, and
benchmarked two versions of it: a buffer-based one and a string-based
one.  Admittedly, there was /changing/ strings (or: creating new ones)
involved, but the string-based one was terribly slow on larger data.
I will be writing about this with more details in a future blog post
(which is largely written and waits for its time).

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: How to test if the current line contains only white-spache?

[Rolf Ade]

Emanuel Berg <embe8573@student.uu.se> writes:
> Rolf Ade <rolf@pointsman.de> writes:
>
>> Works fine and is much simpler. Thanks.
>
> Here is another solution that is all C, and doesn't
> move point. Is that an advantage? ... (Open question.)
> [...]
> (defun blank-line-p ()
>   (string-match "^[[:space:]]*$"
>                 (buffer-substring-no-properties
>                  (line-beginning-position)
>                  (line-end-position) )))

That in fact opened my thinking about the real problem a bit. I 
wasn't aware of line-beginning-position and line-end-position. Lesser
moving the point around may help in finding a better solution.

Btw, what should this -p naming convention signal to me?

Re: How to test if the current line contains only white-spache?

[Stefan Monnier]

> Btw, what should this -p naming convention signal to me?

That it's a "p"redicate.


        Stefan

Re: How to test if the current line contains only white-spache?

[Emanuel Berg]

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

>> Btw, what should this -p naming convention signal
>> to me?
>
> That it's a "p"redicate.

Here [1] it says

    A predicate is a function that tests for some
    condition involving its arguments and returns nil
    if the condition is false, or some non-nil value
    if the condition is true.

[1] https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node69.html

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: How to test if the current line contains only white-spache?

[Emanuel Berg]

Rolf Ade <rolf@pointsman.de> writes:

> Lesser moving the point around may help in finding
> a better solution.

Intuitively, it feels good not moving the point around
too much from Elisp.

Because, moving point around emulates how a human
would solve the problem interactively (i.e., with the
keyboard) contrary to how a computer could just access
the data exactly where it is without any detour.

That said, I often move point around from Elisp (with
`save-excursion') and I have yet to experience a real
problem whose solution was not moving the
point around.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: How to test if the current line contains only white-spache?

[Rolf Ade]

Emanuel Berg <embe8573@student.uu.se> writes:
> Rolf Ade <rolf@pointsman.de> writes:
>
>> Lesser moving the point around may help in finding
>> a better solution.
>
> Intuitively, it feels good not moving the point around
> too much from Elisp.

Yes, this is, what my instinct also telling me. But this instinct was
trained by other programming languages and environments. I'm aware, that
it may be not applicable to emacs lisp / emacs.

> Because, moving point around emulates how a human
> would solve the problem interactively (i.e., with the
> keyboard) contrary to how a computer could just access
> the data exactly where it is without any detour.

It's not so much the "moving point around emulates how a human would
solve the problem interactively" aspect, that feels suspicious to
me. It's more the "doing things by banking on side effects of function
calls" aspect (the "side effect" I'm talking about is moving the point
around).

For example within the emacs lisp code, I'm working atm I've a defun,
that moves point, then remembers the current point position, then calls
another defun, that further moves the point around and then back again
in my first defun I'm working on the so defind region.

Discussing programming concepts at such 'meta level' is difficult. But
maybe some may express their thinking about this. Is this 'moving point
around' in emacs lisp programming code the "right thing" to do (just
wrap it into a save-excursion and you're fine) or is it a signal, that I
haven't found the "right" way to takle the problem at hand with emacs
lisp?

Re: How to test if the current line contains only white-spache?

[Marcin Borkowski]

On 2015-11-19, at 14:54, Rolf Ade <rolf@pointsman.de> wrote:

> Yes, this is, what my instinct also telling me. But this instinct was
> trained by other programming languages and environments. I'm aware, that
> it may be not applicable to emacs lisp / emacs.

And you're right: it's not.

> Discussing programming concepts at such 'meta level' is difficult. But
> maybe some may express their thinking about this. Is this 'moving point
> around' in emacs lisp programming code the "right thing" to do [...]

Yes it is.

See e.g. answers to this question:
http://emacs.stackexchange.com/questions/2120/how-to-insert-text-after-point
(not the same case, but similar) or many definitions in Emacs core.

You can e.g. grep for `save-excursion' in simple.el and other places.
A few highlights: check the definitions of `line-number-at-pos',
`kill-line', `insert-buffer', `next-line', `mark-word' and many others.
It turns out that e.g. this is quite a common idiom:

(save-excursion
  (move-point-someplace-of-interest)
  (point))

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: How to test if the current line contains only white-spache?

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

> On 2015-11-19, at 14:54, Rolf Ade
> <rolf@pointsman.de>
> wrote:
>
>> Yes, this is, what my instinct also telling me.
>> But this instinct was trained by other programming
>> languages and environments. I'm aware, that it may
>> be not applicable to emacs lisp / emacs.
>
> And you're right: it's not.
>
>> Discussing programming concepts at such 'meta level'
>> is difficult. But maybe some may express their
>> thinking about this. Is this 'moving point around'
>> in emacs lisp programming code the "right thing" to
>> do [...]
>
> Yes it is.

I don't think you can be categorical about it.

`save-excursion' and `save-window-excursion' are there
because they are useful. But just because they are
useful doesn't mean they should always be used.

As for "side-effects" that is the phantom menace the
Haskell buffs came up with, when actually side effects
are the reason we use computers.

Rather, in this case it is clear which is preferable
of

    (save-excursion (beginning-of-line) (point))

and

    (line-beginning-position)

The code is easier and faster to write, read,
and understand.

This is even more true when the example isn't as basic
as that, but when everything appears in nested forms
and loops and what have you. If you rely on moving
point around, this will demand of you to be a better
programmer than you would have to be, less it will get
out of hands pretty quickly.

That is one aspect. The other aspect is that often
moving point to the correct place to extract some data
seems straightforward in the lab. In the field all
sorts of unexpected situations appear and suddenly
point doesn't land where it should (or remotely so!).
Now the code once again can quickly get out of hands
if you try to compensate if `looking-at' something
`forward-char' else - and so on: not good!

Note that save-excursion isn't only used to get data
but perhaps most often to seemingly reset the state
after something is done so tho the user is aware it
happened (because he struck the command) he won't be
bothered with the buffer flicking by in the process.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: How to test if the current line contains only white-space?

[Rolf Ade]

Emanuel Berg <embe8573@student.uu.se> writes:
> As for "side-effects" that is the phantom menace the
> Haskell buffs came up with, when actually side effects
> are the reason we use computers.

Nah, it's not that easy.

("I don't think you can be categorical about it." ;-)

> Rather, in this case it is clear which is preferable
> of
>
>     (save-excursion (beginning-of-line) (point))
>
> and
>
>     (line-beginning-position)
>
> The code is easier and faster to write, read,
> and understand.

Yes. That are general principles and they are important judgement rules
for me. (I'd sort it understand, read, write, but anyway.)

> This is even more true when the example isn't as basic
> as that, but when everything appears in nested forms
> and loops and what have you. If you rely on moving
> point around, this will demand of you to be a better
> programmer than you would have to be, less it will get
> out of hands pretty quickly.

Well, yeah. If you start digging a bit more into emacs lisp programming,
as I do atm, a lot of details showing up. While I enjoy that emacs, the
editor, mostly do The Right Thing depending on the "context" (e.g mode
of the buffer) it makes me nervous that within emacs, the programming
enviroment, the effect of my elisp code often depends on settings and
circumstances that are not under my (the programmer) control. (And more
important I may not know about. The one I know about I'm able to
handle.)

In the current, very simple case ("How to test if the current line
contains only white-space?") I learned the difference between
looking-at and looking-at-p. At some stage I used beginning-of-line-text
and quickly realized that the result of that defun depends on
adaptive-fill-mode being on or off. And so on. 

> That is one aspect. The other aspect is that often
> moving point to the correct place to extract some data
> seems straightforward in the lab. In the field all
> sorts of unexpected situations appear and suddenly
> point doesn't land where it should (or remotely so!).
> Now the code once again can quickly get out of hands
> if you try to compensate if `looking-at' something
> `forward-char' else - and so on: not good!

Yeah. See above.

Re: How to test if the current line contains only white-space?

[Rolf Ade]

Emanuel Berg <embe8573@student.uu.se> writes:
> As for "side-effects" that is the phantom menace the
> Haskell buffs came up with, when actually side effects
> are the reason we use computers.

Nah, it's not that easy.

("I don't think you can be categorical about it." ;-)

> Rather, in this case it is clear which is preferable
> of
>
>     (save-excursion (beginning-of-line) (point))
>
> and
>
>     (line-beginning-position)
>
> The code is easier and faster to write, read,
> and understand.

Yes. That are general principles and they are important judgement rules
for me. (I'd sort it understand, read, write, but anyway.)

> This is even more true when the example isn't as basic
> as that, but when everything appears in nested forms
> and loops and what have you. If you rely on moving
> point around, this will demand of you to be a better
> programmer than you would have to be, less it will get
> out of hands pretty quickly.

Well, yeah. If you start digging a bit more into emacs lisp programming,
as I do atm, a lot of details showing up. While I enjoy that emacs, the
editor, mostly do The Right Thing depending on the "context" (e.g mode
of the buffer) it makes me nervous that within emacs, the programming
enviroment, the effect of my elisp code often depends on settings and
circumstances that are not under my (the programmer) control. (And more
important I may not know about. The one I know about I'm able to
handle.)

In the current, very simple case ("How to test if the current line
contains only white-space?") I learned the difference between
looking-at and looking-at-p. At some stage I used beginning-of-line-text
and quickly realized that the result of that defun depends on
adaptive-fill-mode being on or off. And so on. 

> That is one aspect. The other aspect is that often
> moving point to the correct place to extract some data
> seems straightforward in the lab. In the field all
> sorts of unexpected situations appear and suddenly
> point doesn't land where it should (or remotely so!).
> Now the code once again can quickly get out of hands
> if you try to compensate if `looking-at' something
> `forward-char' else - and so on: not good!

Yeah. See above.

Re: How to test if the current line contains only white-spache?

[Marcin Borkowski]

On 2015-11-20, at 00:58, Emanuel Berg <embe8573@student.uu.se> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> On 2015-11-19, at 14:54, Rolf Ade
>> <rolf@pointsman.de>
>> wrote:
>>
>>> Yes, this is, what my instinct also telling me.
>>> But this instinct was trained by other programming
>>> languages and environments. I'm aware, that it may
>>> be not applicable to emacs lisp / emacs.
>>
>> And you're right: it's not.
>>
>>> Discussing programming concepts at such 'meta level'
>>> is difficult. But maybe some may express their
>>> thinking about this. Is this 'moving point around'
>>> in emacs lisp programming code the "right thing" to
>>> do [...]
>>
>> Yes it is.
>
> I don't think you can be categorical about it.

Of course I can.  Though maybe I shouldn't.  ;-)

But I don't say that this is a general rule, always applicable.  Just
that it is a fine pattern in Elisp coding.

> `save-excursion' and `save-window-excursion' are there
> because they are useful. But just because they are
> useful doesn't mean they should always be used.
>
> As for "side-effects" that is the phantom menace the
> Haskell buffs came up with, when actually side effects
> are the reason we use computers.
>
> Rather, in this case it is clear which is preferable
> of
>
>     (save-excursion (beginning-of-line) (point))
>
> and
>
>     (line-beginning-position)
>
> The code is easier and faster to write, read,
> and understand.

Is it really clear?  I'm not sure.

Besides, I've just checked the /implementation/ of
`line-beginning-position', and I have some bad news for you.  I'm not
fluent in C, nut AFAICT, it's even uglier than the Elisp variant: there
is no `save-excursion', just a temporary variable for the original
position of point (which is how `save-excursion' probably has to work
anyway).

So, how is the C `line-beginning-position' better than

(defun elisp-line-beginning-position ()
  (save-excursion (beginning-of-line) (point)))?

(apart from being less general)?  It is just /faster/, but not more
/elegant/ or /pure/.

> This is even more true when the example isn't as basic
> as that, but when everything appears in nested forms
> and loops and what have you. If you rely on moving
> point around, this will demand of you to be a better
> programmer than you would have to be, less it will get
> out of hands pretty quickly.

Aren't /abstractions/ (like functions and/or macros) there to help me
with that?

> That is one aspect. The other aspect is that often
> moving point to the correct place to extract some data
> seems straightforward in the lab. In the field all
> sorts of unexpected situations appear and suddenly
> point doesn't land where it should (or remotely so!).
> Now the code once again can quickly get out of hands
> if you try to compensate if `looking-at' something
> `forward-char' else - and so on: not good!

Could you give a concrete example where your technique is superior
because of that?

> Note that save-excursion isn't only used to get data
> but perhaps most often to seemingly reset the state
> after something is done so tho the user is aware it
> happened (because he struck the command) he won't be
> bothered with the buffer flicking by in the process.

Of course, many commands (like `mark-word', for instance), are
/supposed/ to do something without moving the point.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: How to test if the current line contains only white-space?

[Emanuel Berg]

Rolf Ade <rolf@pointsman.de> writes:

> Well, yeah. If you start digging a bit more into
> emacs lisp programming, as I do atm, a lot of
> details showing up. While I enjoy that emacs, the
> editor, mostly do The Right Thing depending on the
> "context" (e.g mode of the buffer) it makes me
> nervous that within emacs, the programming
> enviroment, the effect of my elisp code often
> depends on settings and circumstances that are not
> under my (the programmer) control. (And more
> important I may not know about. The one I know about
> I'm able to handle.)
>
> In the current, very simple case ("How to test if
> the current line contains only white-space?")
> I learned the difference between looking-at and
> looking-at-p. At some stage I used
> beginning-of-line-text and quickly realized that the
> result of that defun depends on adaptive-fill-mode
> being on or off. And so on.

That doesn't sound like a good feeling and to track
such influences is not a straightforward task.
But this concern never bothered me and I can't recall
ever being punished for not being concerned, either,
so if you are lucky (?) you are not in any trouble,
you are just worried because potentially there could
be trouble.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: How to test if the current line contains only white-spache?

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

>> I don't think you can be categorical about it.
>
> Of course I can. Though maybe I shouldn't. ;-)

"Ho ho ho" - I heard that one in the
techno-incubator...

>> (save-excursion (beginning-of-line) (point))
>> and
>> (line-beginning-position)
>> The code is easier and faster to write, read, and understand.

> Is it really clear? I'm not sure.

It consists of fewer letters and the words express the
return value explicitly. With

    (save-excursion (beginning-of-line) (point))

you have a combination of three different
forms/functions with Emacs-specific lingo at that, and
that combination/lingo has to make sense to you.

> Besides, I've just checked the /implementation/ of
> `line-beginning-position', and I have some bad news
> for you. I'm not fluent in C, nut AFAICT, it's even
> uglier than the Elisp variant: there is no
> `save-excursion' just a temporary variable for the
> original position of point

So it does move point? The help says "This function
does not move point." - that might refer to the user
experience and not the implementation tho. (So the
user knows he doesn't have to enclose it with
`save-excursion'.)

> So, how is the C `line-beginning-position' better than
>
> (defun elisp-line-beginning-position ()
> (save-excursion (beginning-of-line) (point)))?
>
> (apart from being less general)? It is just /faster/,
> but not more /elegant/ or /pure/.

It is less general (i.e., more to the, eh, "point") -
but it is also more general since it is included in
the vanilla Emacs.

As for elegance and purity those algorithms from the
religio-mythical age are discontinued.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: How to test if the current line contains only white-space?

[Rolf Ade]

Emanuel Berg <embe8573@student.uu.se> writes:
>
> That doesn't sound like a good feeling and to track
> such influences is not a straightforward task.
> But this concern never bothered me and I can't recall
> ever being punished for not being concerned, either,
> so if you are lucky (?) you are not in any trouble,
> you are just worried because potentially there could
> be trouble.

So you cultivates a style of: invent something useful and release it, as
fas as it works for you. If it's useful, your user will put your noise
on the not taken into account influences, anyway? (Not necessary a bad
style, btw.)

But you brought me back to reality. It's me, which want that certain
funktionality and as long, as it works for me: fine.

Re: How to test if the current line contains only white-space?

[Emanuel Berg]

Rolf Ade <rolf@pointsman.de> writes:

>> That doesn't sound like a good feeling and to track
>> such influences is not a straightforward task.
>> But this concern never bothered me and I can't
>> recall ever being punished for not being concerned,
>> either, so if you are lucky (?) you are not in any
>> trouble, you are just worried because potentially
>> there could be trouble.
>
> So you cultivates a style of: invent something
> useful and release it, as fas as it works for you.
> If it's useful, your user will put your noise on the
> not taken into account influences, anyway? (Not
> necessary a bad style, btw.)

The best thing is to write software that is used.
If sometimes you are the sole user, it is still used.
With the editor, bugs will be found and until then
there is no real harm to it as this isn't something
used in a space shuttle or anything like that.

If you, as a matter of principle want to be serious
about finding bugs, I don't have a snappy answer how
to root out the issues you describe.

But, here is an article I wrote some years ago on
testing [1] - you might find it useful, but there is
no mention of "influences". If you write such
a paragraph, be sure to mail it to me and I'll include
it :)

Testing

Testing is often put forward as a way to find bugs at
an early stage. It requires little effort and may pay
off huge: not having to retract shipped copies, or
publish patches, and so on.

This holds when testing is compared to
Formal Verification, the more scientific approach
(rather than engineering). With verification, a vast
analytic effort produces a result that can be hard to
grasp. By contrast, testing reveals bugs that can be
fixed instantly, upon detection. Also, testing tests
the real thing. Verification requires a model which
itself may be wrong. Upon success, that only proves
the model to be correct, not the application itself.

The key aspect to testing is to actually do it.
Already at that point, there is a huge advantage
compared to not testing at all. Beyond that, it is
uncertain that more refined methods produce
better results.

Consider the volume factor: if a simple test
method can be employed massively, it is probably
preferable to a more refined method, that only covers
patches of the test field.

If a plethora of test methods are employed, each test
should have an explicit purpose, and/or a distinct
scope. In practice, make a list, and have all tests
automatically and sequentially invoked by a script or
shell function. And don't forget the README file!

For example, one test could enforce that every line of
source code is executed at least once. Most likely
this will require several invocations. To achieve
this, there are again benefits in modular code: each
function should be called at least once, and the
return value fetched and examined. Each procedure
should be invoked and brought to conclusion. And each
interface should be covered in full, including
optional parameters.

Beneath that, it gets more fine-grained, as the
control logic - iteration and branching - must be
taken into account. To help humans visualize the
execution, a directed, cyclic graph could illustrate
the execution logic and flow.

The test that every line of code can execute sensibly
is intended to track bugs that are not syntactical, so
thus will compile, but, once executed, will either
bring a halt to the execution or worse, further down
the road produce a bogus result.

Another way to test focuses on input data. This method
is tangential to the notion of a piece of software as
a black box which maps inputs to outputs. Automatic,
brute force testing with random input data should not
be shunned at. Input data must be valid, but must not
necessarily make sense: with volume, in time, what
makes sense will be tested as well.

If a more refined approach is desired, testing could
be based on input cases, that are qualitatively
distinct. Setup these manually if need be.
For example, with the data of a student database, such
cases could be the empty set (= zero students),
a singe student, all students, only female students,
and so on. Cases that might strike you as unrealistic
or even impossible should not be avoided, as long as
they are valid - on the contrary, those border cases
can reveal shortcomings that sensible inputs cannot.
Indeed, the purpose of testing is to break the
examined application, thus revealing the bug that made
it happen.

(Article from 2013. Minor revision 2015.)

[1] http://user.it.uu.se/~embe8573/testing.txt

-- 
underground experts united
http://user.it.uu.se/~embe8573

looking-at-p slower than looking-at

[Nicolas Richard]

Marcin Borkowski <mbork@mbork.pl> writes:

> You might also (depending on your use-case) want to use looking-at-p,
> which is marginally slower than looking-at, but does not modify match
> data.

Why is it slower and how much slower is it ? I don't see how it can
happen from its implementation:

(defsubst looking-at-p (regexp)
  "\
Same as `looking-at' except this function does not change the match data."
  (let ((inhibit-changing-match-data t))
    (looking-at regexp)))

thanks,

-- 
Nico.

Re: How to test if the current line contains only white-spache?

[Nicolas Richard]

Rolf Ade <rolf@pointsman.de> writes:
> For some random minor elisp code I need to know, if the current line
> contains only white-space characters[1].
>
> I came up with this somewhat convoluted code:
>
> (beginning-of-line)
> (skip-chars-forward " \t")
> (let ((text-start (current-column)))
>   (end-of-line)
>   (if (= text-start (current-column))
>       t
>     nil)

FWIW I would do :
(save-excursion
  (beginning-of-line)
  (skip-chars-forward " \t")
  (eolp))

but IANAL(isper).

-- 
Nico.

Re: looking-at-p slower than looking-at

[Barry Margolin]

In article <mailman.675.1448463102.31583.help-gnu-emacs@gnu.org>,
 Nicolas Richard <nrichard@ulb.ac.be> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
> 
> > You might also (depending on your use-case) want to use looking-at-p,
> > which is marginally slower than looking-at, but does not modify match
> > data.
> 
> Why is it slower and how much slower is it ? I don't see how it can
> happen from its implementation:
> 
> (defsubst looking-at-p (regexp)
>   "\
> Same as `looking-at' except this function does not change the match data."
>   (let ((inhibit-changing-match-data t))
>     (looking-at regexp)))
> 
> thanks,

It takes a tiny amount of time to bind the variable 
inhibit-changing-match-data. That's why it's a little slower.

On the other hand, it doesn't have to set the internal variables that 
hold the match data, so maybe they cancel out.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: looking-at-p slower than looking-at

[Marcin Borkowski]

On 2015-11-25, at 14:58, Nicolas Richard <nrichard@ulb.ac.be> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> You might also (depending on your use-case) want to use looking-at-p,
>> which is marginally slower than looking-at, but does not modify match
>> data.
>
> Why is it slower and how much slower is it ? I don't see how it can
> happen from its implementation:
>
> (defsubst looking-at-p (regexp)
>   "\
> Same as `looking-at' except this function does not change the match data."
>   (let ((inhibit-changing-match-data t))
>     (looking-at regexp)))

One more function call and one more variable binding.  IMHO it /must/ be
slower, though I think the effect is negligible.

OTOH, this trivial and unscientific test:

(setq foo "foo")
(benchmark 10000000 (looking-at foo))
(benchmark 10000000 (looking-at-p foo))

was not conclusive.  (AFAIU, it is of utmost importance that you don't
use literal strings in such a test, since then it is much more probable
that GC will kick in.  Am I right?)

> thanks,

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: How to test if the current line contains only white-spache?

[Marcin Borkowski]

On 2015-11-25, at 15:04, Nicolas Richard <nrichard@ulb.ac.be> wrote:

> Rolf Ade <rolf@pointsman.de> writes:
>> For some random minor elisp code I need to know, if the current line
>> contains only white-space characters[1].
>>
>> I came up with this somewhat convoluted code:
>>
>> (beginning-of-line)
>> (skip-chars-forward " \t")
>> (let ((text-start (current-column)))
>>   (end-of-line)
>>   (if (= text-start (current-column))
>>       t
>>     nil)
>
> FWIW I would do :
> (save-excursion
>   (beginning-of-line)
>   (skip-chars-forward " \t")
>   (eolp))
>
> but IANAL(isper).

Nice!  And quite possibly faster, since no regex is involved.  OTOH, I'm
not sure whether this (or any other solution, for that matter) would
work with visual lines (or what it actually /should/ do).

Regards,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: looking-at-p slower than looking-at

[Marcin Borkowski]

On 2015-11-25, at 16:48, Barry Margolin <barmar@alum.mit.edu> wrote:

> In article <mailman.675.1448463102.31583.help-gnu-emacs@gnu.org>,
>  Nicolas Richard <nrichard@ulb.ac.be> wrote:
>
>> Marcin Borkowski <mbork@mbork.pl> writes:
>> 
>> > You might also (depending on your use-case) want to use looking-at-p,
>> > which is marginally slower than looking-at, but does not modify match
>> > data.
>> 
>> Why is it slower and how much slower is it ? I don't see how it can
>> happen from its implementation:
>> 
>> (defsubst looking-at-p (regexp)
>>   "\
>> Same as `looking-at' except this function does not change the match data."
>>   (let ((inhibit-changing-match-data t))
>>     (looking-at regexp)))
>> 
>> thanks,
>
> It takes a tiny amount of time to bind the variable 
> inhibit-changing-match-data. That's why it's a little slower.
>
> On the other hand, it doesn't have to set the internal variables that 
> hold the match data, so maybe they cancel out.

Ah, I didn't think of that.  Stupid me.  (That might be the answer to
the question why my benchmarks were inconclusive.)

Thanks,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: looking-at-p slower than looking-at

[Michael Heerdegen]

Marcin Borkowski <mbork@mbork.pl> writes:

> (setq foo "foo")
> (benchmark 10000000 (looking-at foo))
> (benchmark 10000000 (looking-at-p foo))

Don't forget to quote the FORM argument - `benchmark' is a function.


Michael.

Re: looking-at-p slower than looking-at

[Marcin Borkowski]

On 2015-11-25, at 22:28, Michael Heerdegen <michael_heerdegen@web.de> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> (setq foo "foo")
>> (benchmark 10000000 (looking-at foo))
>> (benchmark 10000000 (looking-at-p foo))
>
> Don't forget to quote the FORM argument - `benchmark' is a function.

Oops.  Thanks for the correction!

> Michael.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: looking-at-p slower than looking-at

[Emanuel Berg]

Nicolas Richard <nrichard@ulb.ac.be> writes:

> Why is it slower and how much slower is it ? I don't
> see how it can happen from its implementation

Why wouldn't it be slower? It does more things!

Here is a cool macro that confirms (by testing) that
it is indeed slower:

(defmacro measure-time (&rest body)
  "Measure and return the running time of the code block.
Not mine: http://nullprogram.com/blog/2009/05/28/"
  (declare (indent defun))
  (let ((start (make-symbol "start")))
    `(let ((,start (float-time)))
       ,@body
       (- (float-time) ,start))))

(defsubst looking-at-p (regexp)
  "Same as `looking-at' except this function does not change the match data."
  (let ((inhibit-changing-match-data t))
    (looking-at regexp)))

(insert (format " ; %s" (measure-time (looking-at-p "a")))) ; 1.5974044799804688e-05
(insert (format " ; %s" (measure-time (looking-at   "a")))) ; 1.2874603271484375e-05

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: How to test if the current line contains only white-spache?

[Emanuel Berg]

Nicolas Richard <nrichard@ulb.ac.be> writes:

> FWIW I would do : (save-excursion (beginning-of-line)
> (skip-chars-forward " \t") (eolp))
>
> but IANAL(isper).

You are not a lawyer! - because if so you wouldn't
neglect the above evidence that you are indeed
a lisper!

Or wait... - is it the judges that cannot
neglect evidence?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: looking-at-p slower than looking-at

[Nicolas Richard]

Hi Marcin,

Marcin Borkowski writes:
> On 2015-11-25, at 14:58, Nicolas Richard <nrichard@ulb.ac.be> wrote:
>
>> Marcin Borkowski <mbork@mbork.pl> writes:
>>
>>> You might also (depending on your use-case) want to use looking-at-p,
>>> which is marginally slower than looking-at, but does not modify match
>>> data.
>>
>> Why is it slower and how much slower is it ? I don't see how it can
>> happen from its implementation:
>>
>> (defsubst looking-at-p (regexp)
>>   "\
>> Same as `looking-at' except this function does not change the match data."
>>   (let ((inhibit-changing-match-data t))
>>     (looking-at regexp)))
>
> One more function call and one more variable binding.  IMHO it /must/ be
> slower, though I think the effect is negligible.

I think there's not more function calls (in compiled code) since
looking-at-p is a defsubst (i.e. gets inlined by the byte compiler). My
own gut feeling is that setting inhibit-changing-match-data allows
`looking-at' to take shortcuts, thus making it actually faster.

> (setq foo "foo")
> (benchmark 10000000 (looking-at foo))
> (benchmark 10000000 (looking-at-p foo))

benchmark is a function, so (looking-at(-p) foo) is evaluated first,
returns nil, and that is what is given to benchmark as argument. IOW
it's not benchmarking anything. You need to quote the form or use
benchmark-run (or use M-x benchmark interactively).

You could also use benchmark-run or benchmark-run-compiled instead (they
are macros). I admit that it's not 100% clear from the docstring that
the situation is different, since they both name call their argument
FORM(S). Perhaps the macros have an argument named "BODY" instead of
"FORMS".

> (AFAIU, it is of utmost importance that you don't use literal stringso
> in such a test, since then it is much more probable that GC will kick
> in. Am I right?)

I think the string litterals are read and "consed" only once. I'll try
to convince you :

(benchmark 3 '(message "%c" (incf (aref "a" 0))))
Running this with C-x C-e, I get :
b
c
d
in my *Message* buffer.

Explanation : when you hit C-x C-e, emacs reads the sexp,
thus translating it in a list of symbols, numbers and strings. At this
point, "a" is thus a string in emacs memory. When the code is run, it
modifies "a" inplace : (incf (aref "a" 0)) returns ?b (which is what we
get in *Messages*) but modifies the string by side effect. So on the
second run, the code gets the same string, which is now "b". Similarly
for the third run, where the string is now "c".

It would have been different had I done :
    (benchmark 3 '(message "%c" (incf (aref (string ?a) 0))))
because now the string "a" is re-constructed at run time everytime.

Conclusion : I don't think you need to avoid string litterals to have
less GC.

Nicolas.

Re: looking-at-p slower than looking-at

[Nicolas Richard]

Emanuel Berg <embe8573@student.uu.se> writes:

> Nicolas Richard <nrichard@ulb.ac.be> writes:
>
>> Why is it slower and how much slower is it ? I don't
>> see how it can happen from its implementation
>
> Why wouldn't it be slower? It does more things!

Well, I thought it does less: it doesn't modify match data.

> (defmacro measure-time (&rest body)

side note : you can use benchmark-elapse and others, from benchmark.el

-- 
Nico

Re: How to test if the current line contains only white-spache?

[Rolf Ade]

Nicolas Richard <nrichard@ulb.ac.be> writes:
> Rolf Ade <rolf@pointsman.de> writes:
>> [...]
>
> FWIW I would do :
> (save-excursion
>   (beginning-of-line)
>   (skip-chars-forward " \t")
>   (eolp))

Simple and clear, thanks!

Overall: You guys are incredible. I'm somewhat "glad", I asked for a
better way to do, what my convoluted code snippet does.

It was fun, to sit back and following the discussions, to look at the
several provided proposals, to following the pros and cons and the
whatnot considerations.

Occasionally, one or another argument get ridden to death and to read
this group is surely not the most structured way to improve ones emacs
lisp skills (there are tutorials out there, for that) but it's
intellectual entertaining (at least for a programmer) and, in fact,
educational.

rolf

Re: How to test if the current line contains only white-spache?

[Alex Bennée]

Rolf Ade <rolf@pointsman.de> writes:

<snip>
> Btw, what should this -p naming convention signal to me?

It's a predicate, giving a true/false response. For example see:

http://www.gnu.org/software/emacs/manual/html_node/elisp/Type-Predicates.html#Type-Predicates

--
Alex Bennée

predicates (was: Re: How to test if the current line contains only white-spache?)

[Emanuel Berg]

Alex Bennée <alex.bennee@linaro.org> writes:

> It's a predicate, giving a true/false response.

This is how I understand it:

In practice predicates can return anything.

nil, and the empty list, should be interpreted as *false*.

Anything else - including 0, 1, -1, "", and whatever
you are used to as a substitution/indication for false
are thus to be interpreted as *true* here. (`t' and
everything else are true as well, of course.)

If something sensible can be returned along with the
indication of trueness, that isn't bad and that can be
used for whatever purposes.

This definition is:

    A predicate is a function that tests for some
    condition involving its arguments and returns nil
    if the condition is false, or some non-nil value
    if the condition is true. [1]

However this means several functions that are
predicates are not named as such: e.g., `member',
which

    (member ELT LIST)

    Return non-nil if ELT is an element of LIST.
    Comparison done with `equal'. The value is
    actually the tail of LIST whose car is ELT.

But it is all good. I don't want the language all
-p'd. It is good tho for functions like `char-table-p'
because without it, if it was named "char-table", then
you wouldn't realize upon inspection it is a test,
probably you'd think it was some sort of constructor
or "returner" of a data structure. But with,
`char-valid-p', it is obvious to me at least what the
purpose is so the -p is a bit meaningless. But if it is
meaningless, it might as well be there, so I'm not
saying it should be removed, likewise `member'
shouldn't have the -p appended.

Computers are deterministic but that doesn't mean they
are consistent.

[1] https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node69.html

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: predicates

[Pascal J. Bourguignon]

Emanuel Berg <embe8573@student.uu.se> writes:

> Alex Bennée <alex.bennee@linaro.org> writes:
>
>> It's a predicate, giving a true/false response.
>
> This is how I understand it:
>
> In practice predicates can return anything.
>
> nil, and the empty list, should be interpreted as *false*.

They return a generalized boolean, which can indeed be anything.

> Computers are deterministic but that doesn't mean they
> are consistent.

One notable predicate that returns something useful not obtainable
otherwise, is:
              
   (digit-char-p ?4) --> 4

You could use: 
 
    (ignore-errors (parse-integer (string ?4))) --> 4

but parse-integer uses digit-char-p which is the more fundamental
operation.

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: predicates

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

> One notable predicate that returns something useful
> not obtainable otherwise, is:
>
>    (digit-char-p ?4) --> 4
>
> You could use:
>
>     (ignore-errors (parse-integer (string ?4))) --> 4
>
> but parse-integer uses digit-char-p which is the
> more fundamental operation.

And this is what I love with Lisp. There is an endless
world to (re)discover. As soon as you reach one level,
you realize there is another which you didn't
know existed.

-- 
underground experts united
http://user.it.uu.se/~embe8573