unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
* Why isn't ert-buffer.el part of Emacs?
@ 2014-06-13 14:54 Thorsten Jolitz
  2014-06-15  1:43 ` Stefan Monnier
  0 siblings, 1 reply; 13+ messages in thread
From: Thorsten Jolitz @ 2014-06-13 14:54 UTC (permalink / raw)
  To: help-gnu-emacs


Hi List, 

I recently discovered 'ert-buffer.el' and find it very useful. It is
introduced and discussed here:

http://emacs.1067599.n5.nabble.com/Running-ert-tests-on-buffers-in-rst-el-and-elsewhere-td217849.html

I wonder why such a generally useful library isn't included in Emacs (I
don't even find it in the package repos)? It allows to easily compare
buffer content, point and mark position before and after some action.

E.g. for testing the outorg conversion between programming-modes and
org-mode, I used it for a kind of 'do/undo test' (name coined by me)
that really saves me a lot of test-writing work:

It works like this:

#+begin_src emacs-lisp
(ert-deftest outorg-test-conversion ()
  "Test outorg conversion to and from Org."
  (let ((curr-buf-initial-state
	 (with-current-buffer "*outorg-test-buffer*"
	   (ert-Buf-from-buffer))))
    (should
     (ert-equal-buffer
      (outorg-test-cmd)
      curr-buf-initial-state
      t))))
#+end_src

With `ert-Buf-from-buffer' I can take a snapshot of the buffer before
conversion (-> curr-buf-initial-state), and the 't' in 

#+BEGIN_SRC emacs-lisp
  (ert-equal-buffer
   (outorg-test-cmd)
   curr-buf-initial-state
   t)
#+END_SRC

says that this same initial snapshot is used for comparison with the
buffer after the test.

The `outorg-test-cmd' does the following steps:

 1. convert programming-mode buffer to org (in temp buffer)
 2. activate undo-tree-mode
 3. call some given org command interactively
 4. store the buffer-undo-tree
 5. copy changes from modified org buffer back to programming-mode
    buffer
 6. convert programming-mode buffer to (temp) org buffer again
    (i.e. repeat step 1.)
 7. set saved undo-tree as buffer-undo-tree of new temp-buffer
 8. call undo-tree-undo to revert all changes
 9. copy changes from modified org buffer back to programming-mode
    buffer (repeat step 5.)

When the conversion itself has no permanent side-effects, the
programming-mode buffer should look exactly as before after these
steps, no matter what org command was called in the temporary org-mode
edit buffer. 

I would have had to reimplement 'ert-buffer.el' for this if it had not
existed already, and I can imagine others find themselves in the same
situation. 

PS

I had to introduce a few hacks because inside

#+BEGIN_SRC emacs-lisp
(ert-deftest outorg-test-conversion ()
  "Test outorg conversion to and from Org."
  (let ((curr-buf-initial-state
	 (with-current-buffer "*outorg-test-buffer*"
	   (ert-Buf-from-buffer)))) ...))
#+END_SRC

it seems not possible to get info from current-buffer (the buffer that
is current when `ert-run-tests-interactively' is called), because
(current-buffer) inside the `let' expression is already a different
(temp) buffer, and the empty argument list () seems to be there only
for cosmetic reasons. 

I ended up using hardcoded references to global variables and names,
and writing a wrapper function `outorg-test-run-ert' that would set
these globals first and then call `ert-run-tests-interactively', but
that feels like a hack. Is there a way to avoid it?

-- 
cheers,
Thorsten




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Why isn't ert-buffer.el part of Emacs?
       [not found] <mailman.3576.1402671325.1147.help-gnu-emacs@gnu.org>
@ 2014-06-13 23:15 ` Emanuel Berg
  2014-06-14  0:24   ` Grant Rettke
                     ` (3 more replies)
  0 siblings, 4 replies; 13+ messages in thread
From: Emanuel Berg @ 2014-06-13 23:15 UTC (permalink / raw)
  To: help-gnu-emacs

Thorsten Jolitz <tjolitz@gmail.com> writes:

> I recently discovered 'ert-buffer.el' and find it
> very useful. It is introduced and discussed here
> ... I wonder why such a generally useful library
> isn't included in Emacs (I don't even find it in the
> package repos)?

I stopped reading here, because I don't have any
comments on that specific software.

But, in general, I have found tons of useful stuff that
isn't included, and I have written tons of stuff that I
think should be included, perhaps not my implementation
specifically, but rather the functionality.

And often when I miss something I think - "can it
really be that no one got this idea before me?" - and I
always answer "no, that can't be" because what I want
isn't any eccentric stuff anyway. But what happens is I
still write it myself because I don't know how to find
it. I enjoy writing Elisp, but I don't enjoy browsing
the Emacs Wiki, or Googling for that matter. When I
write Elisp I know what has to be done - when I Google,
it is all so frustrating - how do I phrase that? can
that be that page? no? why not? etc. - I usually phrase
the problem as exact as I can, Google once, try the
first hit, and if no luck, then I write it. It is more
important not to be frustrated than to be
efficient. Besides, do it often enough, your Elisp
skills will "catch up" and for quick fixes Google will
eventually even loose time-wise. Still, if I could just
get it, I would.

I suppose the reason why not more stuff is included in
general is that there is so much stuff around, and it
is so easy to "install" it yourself if you just have
the code. If everything was included, Emacs would just
be all over the place. Remember that Emacs isn't
"modular" in the sense that there is one namespace
(which explains the elaborate use of prefixes in
function names: gnus-group-whatever-what-have-you).

Still, one has to wonder by which standards things are
included? I suppose the maintainers and otherwise
developers of Emacs simply have very keen eyes for
this, and include what they know to be
good. Intuitively that sounds like the most sensible
method as well. (But if I'm wrong, and there is some
formal process, it would be interesting to know.)

The other side to it - how to find stuff if you
strongly suspects it is out there - remember the old AI
"expert systems"? They could do anything from
diagnosing health problems to play "20 questions" (and
they would always beat you). I suppose those were a
state machine (a tree) with annotated questions that
would drive the machine to a leaf based on
probability. Wouldn't that be a cool project for some
CS students?

Here is one example of very basic functionality which I
use a lot, and wouldn't have written if it were there
(obviously) or if I could have found it somewhere,
quick and pleasant: it echos the value of a variable,
i.e., compared to describe-variable, it doesn't require
any new pane (so all the documentation etc. isn't
displayed) - it is just very useful (and basic). (I
have it bound to M-m - without a shortcut it isn't as
fast, as always.)

(defun describe-variable-short (var)
  (interactive
   (let*((v            (variable-at-point))
         (var-at-point (not (eq v 0)))
         (v-name       (if var-at-point (symbol-name v)))
         (v-final
          (completing-read
           (format " variable%s: " (if var-at-point
                                       (format " (default %s)" v)
                                       ""))
           obarray
           (lambda (vv)
             (or (get vv 'variable-documentation)
                 (boundp vv) ))
           t    ; require match
           nil  ; no insert to minibuffer (?)
           nil  ; no history
           v-name
          )))
   `(,(intern v-final)) ))
  (message (format " %s: %s" (symbol-name var) (symbol-value var))) )

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


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Why isn't ert-buffer.el part of Emacs?
  2014-06-13 23:15 ` Why isn't ert-buffer.el part of Emacs? Emanuel Berg
@ 2014-06-14  0:24   ` Grant Rettke
       [not found]   ` <mailman.3618.1402705500.1147.help-gnu-emacs@gnu.org>
                     ` (2 subsequent siblings)
  3 siblings, 0 replies; 13+ messages in thread
From: Grant Rettke @ 2014-06-14  0:24 UTC (permalink / raw)
  To: Emanuel Berg; +Cc: Emacs Help

On Fri, Jun 13, 2014 at 6:15 PM, Emanuel Berg <embe8573@student.uu.se> wrote:
> Still, one has to wonder by which standards things are
> included?

The Emacs maintainers are responsible for delivering a complete,
cohesive, functional, and pleasant version of Emacs "out of the box",
"batteries included", without requiring any additional installations
by the user. That is a difficult and thoughtful tasks.

My guess, is that they keep that goal very much in mind, full well
knowing that if people are unhappy with their approach, they will
simply improve upon themselves.

Hard to imagine, but a lot of people do not customize everything :).



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Why isn't ert-buffer.el part of Emacs?
       [not found]   ` <mailman.3618.1402705500.1147.help-gnu-emacs@gnu.org>
@ 2014-06-14  0:39     ` Emanuel Berg
  2014-06-14  0:53     ` Emanuel Berg
  1 sibling, 0 replies; 13+ messages in thread
From: Emanuel Berg @ 2014-06-14  0:39 UTC (permalink / raw)
  To: help-gnu-emacs

Grant Rettke <gcr@wisdomandwonder.com> writes:

> Hard to imagine, but a lot of people do not customize
> everything

What do you mean? :)

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


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Why isn't ert-buffer.el part of Emacs?
       [not found]   ` <mailman.3618.1402705500.1147.help-gnu-emacs@gnu.org>
  2014-06-14  0:39     ` Emanuel Berg
@ 2014-06-14  0:53     ` Emanuel Berg
  2014-06-14  2:19       ` Grant Rettke
  1 sibling, 1 reply; 13+ messages in thread
From: Emanuel Berg @ 2014-06-14  0:53 UTC (permalink / raw)
  To: help-gnu-emacs

Grant Rettke <gcr@wisdomandwonder.com> writes:

> Hard to imagine, but a lot of people do not customize
> everything

aSeriously, customization in the strict sense shouldn't
be included, of course.

I'm talking more about really basic stuff, like echoing
a variable as I mentioned in my previous post.

By the way, this isn't something I saw (or rather
didn't see) just in Emacs: In zsh, I wrote the
following just to convert between bases (!) and present
a uniform input-output interface. zsh is the most
feature rich of all the shells, or so conventional
wisdom claims - but it is the same story - obviously
I'm not the first to want it, and not the first to do
it (somehow), but as I can't find out quickly if it is
there, or if someone else did it, I might as well do it
myself. Again, it is more pleasant that way, though
sometimes less time-efficient.

hex2dec () { echo $(($1)) }
hex2oct () { dec2oct `hex2dec $1` }

dec2hex () {
    hex=`echo "obase=16; $1" | bc`
    lowercase_hex=$hex:l
    echo "0x$lowercase_hex"
}
dec2oct () { echo "obase=8; $1" | bc }

oct2dec () { echo "ibase=8; $1" | bc }
oct2hex () { dec2hex `oct2dec $1` }

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


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Why isn't ert-buffer.el part of Emacs?
  2014-06-14  0:53     ` Emanuel Berg
@ 2014-06-14  2:19       ` Grant Rettke
  0 siblings, 0 replies; 13+ messages in thread
From: Grant Rettke @ 2014-06-14  2:19 UTC (permalink / raw)
  To: Emanuel Berg; +Cc: Emacs Help

On Fri, Jun 13, 2014 at 7:53 PM, Emanuel Berg <embe8573@student.uu.se> wrote:
> I'm talking more about really basic stuff, like echoing
> a variable as I mentioned in my previous post.

From a prioritization perspective... perhaps there are higher
priorities... or rather, there are more things that would have to be
tested due to the change that are not obvious. OK I am guessing, so
now I will stop.



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Why isn't ert-buffer.el part of Emacs?
  2014-06-13 23:15 ` Why isn't ert-buffer.el part of Emacs? Emanuel Berg
  2014-06-14  0:24   ` Grant Rettke
       [not found]   ` <mailman.3618.1402705500.1147.help-gnu-emacs@gnu.org>
@ 2014-06-14 12:22   ` Thorsten Jolitz
       [not found]   ` <mailman.3645.1402748578.1147.help-gnu-emacs@gnu.org>
  3 siblings, 0 replies; 13+ messages in thread
From: Thorsten Jolitz @ 2014-06-14 12:22 UTC (permalink / raw)
  To: help-gnu-emacs

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

> Thorsten Jolitz <tjolitz@gmail.com> writes:
>
>> I recently discovered 'ert-buffer.el' and find it
>> very useful. It is introduced and discussed here
>> ... I wonder why such a generally useful library
>> isn't included in Emacs (I don't even find it in the
>> package repos)?
>
> I stopped reading here, because I don't have any
> comments on that specific software.
>
> But, in general, I have found tons of useful stuff that
> isn't included, and I have written tons of stuff that I
> think should be included, perhaps not my implementation
> specifically, but rather the functionality.

I stopped reading here, because It was ... too long ;)

Of course the Emacs universe is almost infinite, and by far not
everything belongs into core. But since the buffer is *the* fundamental
concept of Emacs, writing tests that compare buffer states appear like a
core task.

Can it be done easily with included ERT libraries (using real world
buffers too)? I'm not the expert here, but at least it is not obvious
how to do it without reimplementing (parts of) ert-buffer.el (probably
over and over again ...)

-- 
cheers,
Thorsten




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Why isn't ert-buffer.el part of Emacs?
       [not found]   ` <mailman.3645.1402748578.1147.help-gnu-emacs@gnu.org>
@ 2014-06-14 12:54     ` Emanuel Berg
  2014-06-14 16:22       ` Drew Adams
  0 siblings, 1 reply; 13+ messages in thread
From: Emanuel Berg @ 2014-06-14 12:54 UTC (permalink / raw)
  To: help-gnu-emacs

Thorsten Jolitz <tjolitz@gmail.com> writes:

>>> I recently discovered 'ert-buffer.el' and find it
>>> very useful. It is introduced and discussed here
>>> ... I wonder why such a generally useful library
>>> isn't included in Emacs (I don't even find it in
>>> the package repos)?
>>>
>> I stopped reading here, because I don't have any
>> comments on that specific software.  But, in
>> general, I have found tons of useful stuff that
>> isn't included, and I have written tons of stuff
>> that I think should be included, perhaps not my
>> implementation specifically, but rather the
>> functionality.
>
> I stopped reading here, because It was ... too long
> ;)
>
> Of course the Emacs universe is almost infinite, and
> by far not everything belongs into core. But since
> the buffer is *the* fundamental concept of Emacs,
> writing tests that compare buffer states appear like
> a core task.

I don't know if the buffer is the fundamental concept
of Emacs, one of many fundamentals, perhaps... But
fundamental or not, I would assume there is tons of
buffer-related stuff around that are just spread across
countless of .el and .emacs files and won't ever make
it to the official release.

For example, I wrote this

(setq
 buffer-menu-buffer-font-lock-keywords
 '(("[[:space:]]+\\([[:digit:]]+\\)[[:space:]]+" (1 font-lock-comment-delimiter-face))
   ("\\*\\(Messages\\|Backtrace\\)\\*" . font-lock-comment-face)
   ("\\*scratch\\*" . 'font-lock-regexp-grouping-construct)
   ("\\*Help\\*"    .  font-lock-constant-face)
   ("\\*Group\\*"   .  font-lock-doc-face)
   ("\\(\\*Man\\) \\(.*\\)\\(\\*\\) "
    (1 font-lock-type-face)
    (2 font-lock-negation-char-face)
    (3 font-lock-type-face) )
   ("[[:space:]%*.]*\\(.*\\.el\\) "                     (1 font-lock-string-face))
   ("[[:space:]%*.]*\\(.*\\.\\(c\\|cpp\\)\\) "          (1 font-lock-function-name-face) )
   ("[[:space:]%*.]*\\(.*\\.\\(txt\\|html\\|htm\\)\\) " (1 font-lock-function-name-face) )
   ("[[:space:]%*.]*\\(.*\\.\\(h\\|hh\\|tex\\)\\) "     (1 font-lock-variable-name-face) )
   ("[[:space:]%*.]*\\( \\.[[:alnum:]\\_\\.\\-]*\\) "   (1 font-lock-type-face) )
   ("\\*w3m\\*" . 'font-lock-regexp-grouping-backslash)
   (".*\\(<[0-9]>\\) " (1 font-lock-negation-char-face))
   ("\\(KILL\\|my-kill\\) " . font-lock-warning-face)
))

so that the buffer menu wouldn't look so boring:
screenshot here -

http://user.it.uu.se/~embe8573/buffer_menu.png

The buffer menu is central but I don't think anyone
will include that just the same.

> Can it be done easily with included ERT libraries
> (using real world buffers too)? I'm not the expert
> here, but at least it is not obvious how to do it
> without reimplementing (parts of) ert-buffer.el
> (probably over and over again ...)

In this particular case, what does it matter? You have
the code you need so just use it, I would say.

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


^ permalink raw reply	[flat|nested] 13+ messages in thread

* RE: Why isn't ert-buffer.el part of Emacs?
  2014-06-14 12:54     ` Emanuel Berg
@ 2014-06-14 16:22       ` Drew Adams
  0 siblings, 0 replies; 13+ messages in thread
From: Drew Adams @ 2014-06-14 16:22 UTC (permalink / raw)
  To: help-gnu-emacs

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

> I wrote this (setq buffer-menu-buffer-font-lock-keywords ...)
> so that the buffer menu wouldn't look so boring: screenshot here -
> http://user.it.uu.se/~embe8573/buffer_menu.png

See attached screenshot.  And this page (with older screenshots):
http://www.emacswiki.org/emacs/BufferMenuPlus


[Unfortunately, this is not available for Emacs 24, unless you
pick up the Emacs 23 version of buff-menu.el.  They changed
buff-menu.el in Emacs 24 to use `tabulated-list-mode', and I
haven't bothered to try to update buff-menu+.el accordingly
(and perhaps never will).]

[-- Attachment #2: throw-buffer-menu.png --]
[-- Type: image/png, Size: 40305 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Why isn't ert-buffer.el part of Emacs?
  2014-06-13 14:54 Thorsten Jolitz
@ 2014-06-15  1:43 ` Stefan Monnier
  2014-06-17 10:25   ` Thorsten Jolitz
  0 siblings, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2014-06-15  1:43 UTC (permalink / raw)
  To: help-gnu-emacs

> I recently discovered 'ert-buffer.el' and find it very useful.  It is
> introduced and discussed here:
> I wonder why such a generally useful library isn't included in Emacs (I
> don't even find it in the package repos)?

I vaguely remember hearing about ert-buffer.el at some point.  I don't
have enough time to investigate its usefulness myself, so I can only
judge it based on how much it's used.

One way to show its usefulness would be to write a patch for Emacs's
test/automated subdirectory showing how it lets us simplify those tests.

I think if such a library is useful, then it belongs in Emacs's core
rather than in GNU ELPA, since we'd probably want to use it for Emacs's
own tests.


        Stefan




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Why isn't ert-buffer.el part of Emacs?
  2014-06-15  1:43 ` Stefan Monnier
@ 2014-06-17 10:25   ` Thorsten Jolitz
  2014-06-17 12:55     ` Stefan Monnier
  0 siblings, 1 reply; 13+ messages in thread
From: Thorsten Jolitz @ 2014-06-17 10:25 UTC (permalink / raw)
  To: help-gnu-emacs

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

>> I recently discovered 'ert-buffer.el' and find it very useful.  It is
>> introduced and discussed here:
>> I wonder why such a generally useful library isn't included in Emacs (I
>> don't even find it in the package repos)?
>
> I vaguely remember hearing about ert-buffer.el at some point.  I don't
> have enough time to investigate its usefulness myself, so I can only
> judge it based on how much it's used.

My question had probably two parts:

 - find out if I miss something in core Emacs that gives me the same
   functionality as ert-buffer.el?

 - raise some attention to ert-buffer.el 's usefullness

> One way to show its usefulness would be to write a patch for Emacs's
> test/automated subdirectory showing how it lets us simplify those tests.

Thats probably a bit over my head, and I don't have the time right now. 

> I think if such a library is useful, then it belongs in Emacs's core
> rather than in GNU ELPA, since we'd probably want to use it for Emacs's
> own tests.

I did write a little extension to it called ert-buffer-report.el (not
yet published) that prints the test results into an Org file, so I can
demonstrate how the library is usefull for me for testing the conversion
between programming modes and org-mode via outorg.el.

When testing this kind of conversion, often my MWEs (mininal working
example) pass the tests, but when I try one of the huge complex
elisp/org documents around (I use e.g. Fabrice Nielson's giant former
init.el and Bernt Hansen's big org-mode.org for this) I get
failures. Easily creating 'black-box' tests for these really big
real-world files/buffers (not just MWEs) with ert-buffer.el comes in
handy.

Here I test a MWE that does expose a bug (which I found by testing big
real-world files). Before running the tests, I do 

,--------------------------------------------------
| M-x ert-buffer-report-toggle-insert-buffer-string
`--------------------------------------------------

so the (short) MWE content BEFORE and AFTER the test is included in the
report. 

1. WITH BUG:

,-------------------------------------------------------
| After 
|  - converting from elisp [BEFORE] to org
|  - running an org-command and storing buffer-undo-tree
|  - converting back from org to elisp
| and then 
|  - converting from elisp to org (again)
|  - undoing changes using stored buffer-undo-tree 
|  - converting back from org to elisp [AFTER]
`-------------------------------------------------------

I get this org-mode report:
 - Point moved
 - content length increased
 - there are content DIFFS between BEFORE and AFTER
thus the test failed due to unwanted conversion side-effects

#########################################################################
* ERT Test Report <2014-06-17 Di 11:42>
** Point, Mark and Content Lenght
 - Point position :: 534 -> 38
 - Mark position :: nil -> nil
 - Content length :: 533 -> 583
** Content DIFF
#+begin_quote
15,19c15,16
< (add-hook 'org-mode-hook (lambda () (abbrev-mode 1)))
< 
< (setq org-todo-keywords
<       (quote ((sequence "TODO(t)" "NEXT(n)" "|" "DONE(d!/!)")
<               (sequence "WAITING(w@/!)" "HOLD(h@/!)" "|" "CANCELLED(c@/!)" "PHONE"))))
---
20a18,21
> ;; #+begin_src emacs-lisp
> ;; (add-hook 'org-mode-hook (lambda () (abbrev-mode 1)))
> ;; (setq org-todo-keywords
> ;;       (quote ((sequence "TODO(t)" "NEXT(n)" "|" "DONE(d!/!)")
> ;;               (sequence "WAITING(w@/!)" "HOLD(h@/!)" "|" "CANCELLED(c@/!)" "PHONE"))))
> ;; #+end_src

#+end_quote
** Buffer Strings
*** Buffer String BEFORE
#+begin_quote

;; *** General

;; **** Configuration

(setq org-indent-mode-turns-on-hiding-stars nil
      org-replace-disputed-keys t
      org-use-speed-commands t)

(add-hook 'org-mode-hook
          (lambda ()
            (local-set-key (kbd "C-c M-o") 'tj/mail-subtree))
          'append)

;; Enable abbrev-mode
(add-hook 'org-mode-hook (lambda () (abbrev-mode 1)))

(setq org-todo-keywords
      (quote ((sequence "TODO(t)" "NEXT(n)" "|" "DONE(d!/!)")
              (sequence "WAITING(w@/!)" "HOLD(h@/!)" "|" "CANCELLED(c@/!)" "PHONE"))))

^@
#+end_quote
*** Buffer String AFTER
#+begin_quote

;; *** General

;; **** Configuration^@

(setq org-indent-mode-turns-on-hiding-stars nil
      org-replace-disputed-keys t
      org-use-speed-commands t)

(add-hook 'org-mode-hook
          (lambda ()
            (local-set-key (kbd "C-c M-o") 'tj/mail-subtree))
          'append)

;; Enable abbrev-mode
;; #+begin_src emacs-lisp
;; (add-hook 'org-mode-hook (lambda () (abbrev-mode 1)))

;; (setq org-todo-keywords
;;       (quote ((sequence "TODO(t)" "NEXT(n)" "|" "DONE(d!/!)")
;;               (sequence "WAITING(w@/!)" "HOLD(h@/!)" "|" "CANCELLED(c@/!)" "PHONE"))))
;; #+end_src

#+end_quote
#########################################################################

It seems that, when converting back from org-mode to elisp, my regexp
that matches emacs-lisp code-blocks in org-mode did not match the block
that contains @ symbols. This seemed strange for me, because I use

,--------------------------------------------------------
| "^#\\+begin_src[[:space:]]+emacs-lisp[^^@]*\n#\\+end_src"
`--------------------------------------------------------

and that negated zero-byte in [^^@]* should really match everything
inside the block delimiters. After some experimenting I figured out that
my regexp was buggy, since I simply inserted ^^@ as three normal chars 

,------
| ^ ^ @
`------

while I should have used  

,----------
| ^ C-q C-@
`----------

to actually use the zero-byte. 


2. WITHOUT BUG:

Repeating this test, this time omitting the buffer strings by calling 

,--------------------------------------------------
| M-x ert-buffer-report-toggle-insert-buffer-string
`--------------------------------------------------

again, I get:


##########################################
* ERT Test Report <2014-06-17 Di 11:59>
** Point, Mark and Content Lenght
 - Point position :: 534 -> 38
 - Mark position :: nil -> nil
 - Content length :: 533 -> 532
** Content DIFF
#+begin_quote
20d19
< 

#+end_quote
** Buffer Strings
*** Buffer String BEFORE
   [buffer-string omitted]
*** Buffer String AFTER
   [buffer-string omitted]
##########################################

Point moved again, what makes the test fail, but isn't relevant in this
case. Now content-length changed by only 1 char, and the DIFF looks like
this would be a newline \n. 

Lets print the content strings again to get a clearer picture:


#################################################################
* ERT Test Report <2014-06-17 Di 12:04>
** Point, Mark and Content Lenght
 - Point position :: 534 -> 38
 - Mark position :: nil -> nil
 - Content length :: 533 -> 532
** Content DIFF
#+begin_quote
20d19
< 

#+end_quote
** Buffer Strings
*** Buffer String BEFORE
#+begin_quote

;; *** General

;; **** Configuration

(setq org-indent-mode-turns-on-hiding-stars nil
      org-replace-disputed-keys t
      org-use-speed-commands t)

(add-hook 'org-mode-hook
          (lambda ()
            (local-set-key (kbd "C-c M-o") 'tj/mail-subtree))
          'append)

;; Enable abbrev-mode
(add-hook 'org-mode-hook (lambda () (abbrev-mode 1)))

(setq org-todo-keywords
      (quote ((sequence "TODO(t)" "NEXT(n)" "|" "DONE(d!/!)")
              (sequence "WAITING(w@/!)" "HOLD(h@/!)" "|" "CANCELLED(c@/!)" "PHONE"))))

^@
#+end_quote
*** Buffer String AFTER
#+begin_quote

;; *** General

;; **** Configuration^@

(setq org-indent-mode-turns-on-hiding-stars nil
      org-replace-disputed-keys t
      org-use-speed-commands t)

(add-hook 'org-mode-hook
          (lambda ()
            (local-set-key (kbd "C-c M-o") 'tj/mail-subtree))
          'append)

;; Enable abbrev-mode
(add-hook 'org-mode-hook (lambda () (abbrev-mode 1)))

(setq org-todo-keywords
      (quote ((sequence "TODO(t)" "NEXT(n)" "|" "DONE(d!/!)")
              (sequence "WAITING(w@/!)" "HOLD(h@/!)" "|" "CANCELLED(c@/!)" "PHONE"))))

#+end_quote
#############################################################################


So point moved from end-of-buffer (BEFORE)

,--------------------------------------------------------------------------
|  (sequence "WAITING(w@/!)" "HOLD(h@/!)" "|" "CANCELLED(c@/!)" "PHONE"))))
| 
| ^@
`--------------------------------------------------------------------------

to 

,---------------------
| **** Configuration^@
`---------------------

(AFTER) and somehow that last empty line where point was disappeared. So
conversion works (almost) fine already ...


Note that I get all the info about point, mark, buffer-content and
buffer-string BEFORE and AFTER for free from ert-buffer.el. Although I
had to write some code to setup the environment for testing outorg
(outorg-test.el), the actual ERT test using ert-buffer.el looks like
this

,-----------------------------------------------------
| (ert-deftest outorg-test-conversion ()
|   "Test outorg conversion to and from Org.[...]"
|   (let ((curr-buf-initial-state
|          (with-current-buffer "*outorg-test-buffer*"
|            (ert-Buf-from-buffer))))
|     (should
|      (ert-equal-buffer
|       (outorg-test-cmd)
|       curr-buf-initial-state
|       t))))
`-----------------------------------------------------

which is short enough I think ...

-- 
cheers,
Thorsten




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Why isn't ert-buffer.el part of Emacs?
  2014-06-17 10:25   ` Thorsten Jolitz
@ 2014-06-17 12:55     ` Stefan Monnier
  2014-06-17 13:32       ` Thorsten Jolitz
  0 siblings, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2014-06-17 12:55 UTC (permalink / raw)
  To: help-gnu-emacs

>  - raise some attention to ert-buffer.el 's usefulness

I suggest you M-x report-emacs-bug requesting inclusion of ert-buffer.el.
And then try to get other people to add their support.


        Stefan




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Why isn't ert-buffer.el part of Emacs?
  2014-06-17 12:55     ` Stefan Monnier
@ 2014-06-17 13:32       ` Thorsten Jolitz
  0 siblings, 0 replies; 13+ messages in thread
From: Thorsten Jolitz @ 2014-06-17 13:32 UTC (permalink / raw)
  To: help-gnu-emacs

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

>>  - raise some attention to ert-buffer.el 's usefulness
>
> I suggest you M-x report-emacs-bug requesting inclusion of ert-buffer.el.
> And then try to get other people to add their support.

Ok, done.

-- 
cheers,
Thorsten




^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2014-06-17 13:32 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <mailman.3576.1402671325.1147.help-gnu-emacs@gnu.org>
2014-06-13 23:15 ` Why isn't ert-buffer.el part of Emacs? Emanuel Berg
2014-06-14  0:24   ` Grant Rettke
     [not found]   ` <mailman.3618.1402705500.1147.help-gnu-emacs@gnu.org>
2014-06-14  0:39     ` Emanuel Berg
2014-06-14  0:53     ` Emanuel Berg
2014-06-14  2:19       ` Grant Rettke
2014-06-14 12:22   ` Thorsten Jolitz
     [not found]   ` <mailman.3645.1402748578.1147.help-gnu-emacs@gnu.org>
2014-06-14 12:54     ` Emanuel Berg
2014-06-14 16:22       ` Drew Adams
2014-06-13 14:54 Thorsten Jolitz
2014-06-15  1:43 ` Stefan Monnier
2014-06-17 10:25   ` Thorsten Jolitz
2014-06-17 12:55     ` Stefan Monnier
2014-06-17 13:32       ` Thorsten Jolitz

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