all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* How do I debug errors in post-command-hook?
@ 2010-07-29 20:30 Tassilo Horn
  2010-07-29 21:33 ` Lennart Borgman
  2010-07-30  0:11 ` Johan Bockgård
  0 siblings, 2 replies; 16+ messages in thread
From: Tassilo Horn @ 2010-07-29 20:30 UTC (permalink / raw)
  To: emacs-devel

Hi all,

how do I debug errors that happen while executing a function in
`post-command-hook'?  The usual debugging facilities like
`toggle-debug-on-error' and `edebug-function' are not triggered in
there...

Background: There seem to be some packages that error when emacs is
started with the --daemon option.  One example is the lusty-explorer's
`lusty-buffer-explorer' function.  It works fine when run in a "normal"
emacs, but I get an error in `post-command-hook' when emacs was
initially started as daemon, and I'd like to know what's going wrong.

Bye,
Tassilo



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

* Re: How do I debug errors in post-command-hook?
  2010-07-29 20:30 How do I debug errors in post-command-hook? Tassilo Horn
@ 2010-07-29 21:33 ` Lennart Borgman
  2010-07-30  0:11 ` Johan Bockgård
  1 sibling, 0 replies; 16+ messages in thread
From: Lennart Borgman @ 2010-07-29 21:33 UTC (permalink / raw)
  To: Tassilo Horn; +Cc: emacs-devel

On Thu, Jul 29, 2010 at 10:30 PM, Tassilo Horn <tassilo@member.fsf.org> wrote:
> Hi all,
>
> how do I debug errors that happen while executing a function in
> `post-command-hook'?  The usual debugging facilities like
> `toggle-debug-on-error' and `edebug-function' are not triggered in
> there...
>
> Background: There seem to be some packages that error when emacs is
> started with the --daemon option.  One example is the lusty-explorer's
> `lusty-buffer-explorer' function.  It works fine when run in a "normal"
> emacs, but I get an error in `post-command-hook' when emacs was
> initially started as daemon, and I'd like to know what's going wrong.

I usually split up functions in post-command-hook like this:

(defun post-fun ()
   (condition-case err
         (post-fun-1)
     (error (message "post-fun: %s" (error-message-string err)))))

(defun post-fun-1 ()
   ...)

When I get an error I do

   M-: (post-fun-1)



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

* Re: How do I debug errors in post-command-hook?
  2010-07-29 20:30 How do I debug errors in post-command-hook? Tassilo Horn
  2010-07-29 21:33 ` Lennart Borgman
@ 2010-07-30  0:11 ` Johan Bockgård
  2010-07-30  6:54   ` Tassilo Horn
  1 sibling, 1 reply; 16+ messages in thread
From: Johan Bockgård @ 2010-07-30  0:11 UTC (permalink / raw)
  To: emacs-devel

Tassilo Horn <tassilo@member.fsf.org> writes:

> Hi all,
>
> how do I debug errors that happen while executing a function in
> `post-command-hook'?  The usual debugging facilities like
> `toggle-debug-on-error' and `edebug-function' are not triggered in
> there...
>
> Background: There seem to be some packages that error when emacs is
> started with the --daemon option.  One example is the lusty-explorer's
> `lusty-buffer-explorer' function.  It works fine when run in a "normal"
> emacs, but I get an error in `post-command-hook' when emacs was
> initially started as daemon, and I'd like to know what's going wrong.

;; I spent a few hours hacking together a solution using
;; signal-hook-function and had written a reply, and just before sending
;; the message I noticed that this actually works:
(defadvice lusty--post-command-function (around intercept activate)
  (condition-case err
      ad-do-it
    ;; Let the debugger run
    ((debug error) (signal (car err) (cdr err)))))



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

* Re: How do I debug errors in post-command-hook?
  2010-07-30  0:11 ` Johan Bockgård
@ 2010-07-30  6:54   ` Tassilo Horn
  2010-07-30 11:58     ` Johan Bockgård
  0 siblings, 1 reply; 16+ messages in thread
From: Tassilo Horn @ 2010-07-30  6:54 UTC (permalink / raw)
  To: emacs-devel; +Cc: Johan Bockgård

On Friday 30 July 2010 02:11:38 Johan Bockgård wrote:

Hi Johan,

> (defadvice lusty--post-command-function (around intercept activate)
>   (condition-case err
>       ad-do-it
>     ;; Let the debugger run
>     ((debug error) (signal (car err) (cdr err)))))

That didn't enter the debugger.  I guess you missed the error as
condition handler.  So I use this advice now:

--8<---------------cut here---------------start------------->8---
(defadvice lusty--post-command-function (around intercept activate)
  (condition-case err
      ad-do-it
    ;; Let the debugger run
    (error (progn (message "%s" err) (debug err)))))
--8<---------------cut here---------------end--------------->8---

And here's the backtrace.

--8<---------------cut here---------------start------------->8---
Debugger entered: ((error "Attempt to modify read-only object"))
  (progn (message "%s" err) (debug err))
  (condition-case err (setq ad-return-value (ad-Orig-lusty--post-command-function)) (error (progn ... ...)))
  (let (ad-return-value) (condition-case err (setq ad-return-value ...) (error ...)) ad-return-value)
  lusty--post-command-function()
  run-hooks(post-command-hook)
  ad-Orig-read-buffer(">> " nil nil)
  (setq ad-return-value (ad-Orig-read-buffer prompt def require-match))
  (let ((completion-styles ...)) (setq ad-return-value (ad-Orig-read-buffer prompt def require-match)))
  (let (ad-return-value) (let (...) (setq ad-return-value ...)) ad-return-value)
  read-buffer(">> ")
  apply(read-buffer ">> " nil)
  (save-window-excursion (apply read-fn lusty-prompt args))
  (unwind-protect (save-window-excursion (apply read-fn lusty-prompt args)) (remove-hook (quote post-command-hook) (quote lusty--post-command-function)) (setq lusty--previous-minibuffer-contents nil lusty--initial-window-config nil lusty--current-idle-timer nil))
  (let ((lusty--highlighted-coords ...) (lusty--matches-matrix ...) (lusty--matrix-column-widths ...) (lusty--matrix-truncated-p nil)) (add-hook (quote post-command-hook) (quote lusty--post-command-function) t) (unwind-protect (save-window-excursion ...) (remove-hook ... ...) (setq lusty--previous-minibuffer-contents nil lusty--initial-window-config nil lusty--current-idle-timer nil)))
  lusty--run(read-buffer)
  (let* ((lusty--active-mode :buffer-explorer) (minibuffer-local-completion-map lusty-mode-map) (buffer ...)) (when buffer (switch-to-buffer buffer)))
  lusty-buffer-explorer()
  call-interactively(lusty-buffer-explorer nil nil)
--8<---------------cut here---------------end--------------->8---

Well, that doesn't help me, right?  The error message was printed
anyway, and the backtrace is the backtrace after leaving
`lusty--post-command-function'.

Bye,
Tassilo



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

* Re: How do I debug errors in post-command-hook?
  2010-07-30  6:54   ` Tassilo Horn
@ 2010-07-30 11:58     ` Johan Bockgård
  2010-07-30 14:23       ` Buffer names are sometimes read-only objects in daemonized emacs (was: How do I debug errors in post-command-hook?) Tassilo Horn
  0 siblings, 1 reply; 16+ messages in thread
From: Johan Bockgård @ 2010-07-30 11:58 UTC (permalink / raw)
  To: emacs-devel

Tassilo Horn <tassilo@member.fsf.org> writes:

> On Friday 30 July 2010 02:11:38 Johan Bockgård wrote:
>
> Hi Johan,
>
>> (defadvice lusty--post-command-function (around intercept activate)
>>   (condition-case err
>>       ad-do-it
>>     ;; Let the debugger run
>>     ((debug error) (signal (car err) (cdr err)))))
>
> That didn't enter the debugger.

You need to turn on debug-on-error.



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

* Buffer names are sometimes read-only objects in daemonized emacs (was: How do I debug errors in post-command-hook?)
  2010-07-30 11:58     ` Johan Bockgård
@ 2010-07-30 14:23       ` Tassilo Horn
  2010-07-30 17:46         ` Buffer names are sometimes read-only objects in daemonized emacs Johan Bockgård
  0 siblings, 1 reply; 16+ messages in thread
From: Tassilo Horn @ 2010-07-30 14:23 UTC (permalink / raw)
  To: emacs-devel; +Cc: Johan Bockgård

On Friday 30 July 2010 13:58:59 Johan Bockgård wrote:

Hi Johan,

> >> (defadvice lusty--post-command-function (around intercept activate)
> >>   (condition-case err
> >>       ad-do-it
> >>     ;; Let the debugger run
> >>     ((debug error) (signal (car err) (cdr err)))))
> >
> > That didn't enter the debugger.
> 
> You need to turn on debug-on-error.

Oh, indeed.  Then it did work, and here's the backtrace.

--8<---------------cut here---------------start------------->8---
Debugger entered--Lisp error: (error "Attempt to modify read-only object")
  put-text-property(0 11 face font-lock-string-face "*GNU Emacs*")
  byte-code("\b\306\x19\211\x1a\203r\0\n@\x11\v\f	\211\x1dGS\x1e\x0eH\307=\2035\0\310\311\x0e\312\x0e\x0e%\210\310\x0e\211T\312\x0e\x0f%\210\202@\0\310\311\x0eT\312\x0e\x10%\210))I\210\fT\211\x14\x0e\x11Y\203k\0\x0e\x12T\211\x16\x12\x0e\x13Y\203c\0\313\314\306\"\210\202i\0\x0e\x14\x0e\x12H\x13\311\x14\nA\211\x12\204\b\0*\306\207" [items item --cl-dolist-temp-- col-vec y path nil 47 put-text-property 0 face throw --cl-block-nil-- last lusty-directory-face lusty-slash-face lusty-file-face optimal-n-rows x n-columns matrix] 9)
  lusty--compute-layout-matrix(("*GNU Emacs*" "*Messages*" "diary" "*scratch*"))
  lusty-refresh-matches-buffer()
  ad-Orig-lusty--post-command-function()
  (setq ad-return-value (ad-Orig-lusty--post-command-function))
  (condition-case err (setq ad-return-value (ad-Orig-lusty--post-command-function)) ((debug error) (signal ... ...)))
  (let (ad-return-value) (condition-case err (setq ad-return-value ...) (... ...)) ad-return-value)
  lusty--post-command-function()
  run-hooks(post-command-hook)
  ad-Orig-read-buffer(">> " nil nil)
  (setq ad-return-value (ad-Orig-read-buffer prompt def require-match))
  (let ((completion-styles ...)) (setq ad-return-value (ad-Orig-read-buffer prompt def require-match)))
  (let (ad-return-value) (let (...) (setq ad-return-value ...)) ad-return-value)
  read-buffer(">> ")
  apply(read-buffer ">> " nil)
  lusty--run(read-buffer)
  lusty-buffer-explorer()
  call-interactively(lusty-buffer-explorer nil nil)
--8<---------------cut here---------------end--------------->8---

Looking at the lusty-explorer code, `lusty--compute-layout-matrix' calls
a defsubst `lusty-propertize-path' which eventually propertizes the
string given as parameter `path', like indicated by the top frame of the
backtrace:

    put-text-property(0 11 face font-lock-string-face "*GNU Emacs*")

But why does that throw an error when emacs is started as a daemon?

And, even in a daemonized emacs, I can eval

   (lusty-propertize-path "*GNU Emacs*")

without any problem.  So it looks like the string "*GNU Emacs*" passed
to that defsubst is somehow read-only.  Grepping the emacs sources the
error seems to be triggered by having that string in pure storage.  But
why?

The string is retrieved by collecting buffers using `walk-windows'
followed by `window-buffer' in combination with `buffer-list'.  Then for
all collected buffers, `buffer-name' is called, and those strings are
then passed to the `lusty-propertize-path' defsubst.

But even this does work in a daemonized emacs, even when I put it at the
front of my .emacs and then start it with emacs --daemon:

(dolist (b (buffer-list))
  (let ((n (buffer-name (get-buffer b))))
    (put-text-property 0 (length n) 'face font-lock-string-face n)))

Thereby I realized that after evaling that, (buffer-name <some-buf>)
will return the propertized string, so it seems that `buffer-name'
doesn't return a string copy but a place in the CL sense.  I'm not sure
if that's correct?  (The same is true for a "normal" emacs.)

Can anyone enlighten me what's going on?

Bye,
Tassilo

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

* Re: Buffer names are sometimes read-only objects in daemonized emacs
  2010-07-30 14:23       ` Buffer names are sometimes read-only objects in daemonized emacs (was: How do I debug errors in post-command-hook?) Tassilo Horn
@ 2010-07-30 17:46         ` Johan Bockgård
  2010-07-30 18:41           ` Tassilo Horn
  0 siblings, 1 reply; 16+ messages in thread
From: Johan Bockgård @ 2010-07-30 17:46 UTC (permalink / raw)
  To: emacs-devel

Tassilo Horn <tassilo@member.fsf.org> writes:

> And, even in a daemonized emacs, I can eval
>
>    (lusty-propertize-path "*GNU Emacs*")

This is obviously a fresh string.

> So it looks like the string "*GNU Emacs*" passed to that defsubst is
> somehow read-only. Grepping the emacs sources the error seems to be
> triggered by having that string in pure storage.

Yes.

> But even this does work in a daemonized emacs, even when I put it at the
> front of my .emacs and then start it with emacs --daemon:
>
> (dolist (b (buffer-list))
>   (let ((n (buffer-name (get-buffer b))))
>     (put-text-property 0 (length n) 'face font-lock-string-face n)))

But this list does not contain "*GNU Emacs*", does it? ("*GNU Emacs*" is
the splash screen buffer. It is created after loading the init files.)

The daemon creates the splash screen via `normal-splash-screen' (instead
of `fancy-startup-screen'). It contains a call to `(rename-buffer "*GNU
Emacs*" t)'. Unlike `get-buffer-create', `rename-buffer' does not make a
copy of the provided string. This is how the pure string ends up in
`buffer-name', AFAICT.

(Modifying a string returned by `buffer-name' is still evil, as it does
not promise to return a fresh string.)



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

* Re: Buffer names are sometimes read-only objects in daemonized emacs
  2010-07-30 17:46         ` Buffer names are sometimes read-only objects in daemonized emacs Johan Bockgård
@ 2010-07-30 18:41           ` Tassilo Horn
  2010-07-30 19:54             ` Wojciech Meyer
  0 siblings, 1 reply; 16+ messages in thread
From: Tassilo Horn @ 2010-07-30 18:41 UTC (permalink / raw)
  To: emacs-devel; +Cc: Johan Bockgård

On Friday 30 July 2010 19:46:28 Johan Bockgård wrote:

> > But even this does work in a daemonized emacs, even when I put it at
> > the front of my .emacs and then start it with emacs --daemon:
> >
> > (dolist (b (buffer-list))
> >   (let ((n (buffer-name (get-buffer b))))
> >     (put-text-property 0 (length n) 'face font-lock-string-face n)))
> 
> But this list does not contain "*GNU Emacs*", does it?

Nope.

> ("*GNU Emacs*" is the splash screen buffer. It is created after
> loading the init files.)
> 
> The daemon creates the splash screen via `normal-splash-screen'
> (instead of `fancy-startup-screen'). It contains a call to
> `(rename-buffer "*GNU Emacs*" t)'. Unlike `get-buffer-create',
> `rename-buffer' does not make a copy of the provided string. This is
> how the pure string ends up in `buffer-name', AFAICT.

But why is the string "*GNU Emacs*" put in pure space?  Because
everything that gets created when loading startup.el will be in pure
space?

> (Modifying a string returned by `buffer-name' is still evil, as it
> does not promise to return a fresh string.)

IMO a function shouldn't need to allow modification of it's return value
explicitly, but instead should warn if that's possible.  But indeed,
evaluating

  (aset (buffer-name) 0 ?g) 

makes my kmailCh3711.tmp buffer a gmailCh3711.tmp buffer.  To be honest,
this is really awkward.  Nobody would guess that modifying a string
returned by some function could have any side effects.

Bye,
Tassilo



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

* Re: Buffer names are sometimes read-only objects in daemonized emacs
  2010-07-30 18:41           ` Tassilo Horn
@ 2010-07-30 19:54             ` Wojciech Meyer
  2010-07-30 20:08               ` Tassilo Horn
  0 siblings, 1 reply; 16+ messages in thread
From: Wojciech Meyer @ 2010-07-30 19:54 UTC (permalink / raw)
  To: Tassilo Horn; +Cc: Johan Bockgård, emacs-devel

Tassilo Horn <tassilo@member.fsf.org>  writes:

> IMO a function shouldn't need to allow modification of it's return value
> explicitly, but instead should warn if that's possible.  But indeed,
> evaluating
>
>   (aset (buffer-name) 0 ?g)

How would you do this? I see that the check can be performed on only at
runtime. Bytecompiler will not warn, because the value might be
propagated, and Lisp is dynamicaly typed. (in simple cases like this it
is apparent, but consider just returning this value from function).

Wojciech



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

* Re: Buffer names are sometimes read-only objects in daemonized emacs
  2010-07-30 19:54             ` Wojciech Meyer
@ 2010-07-30 20:08               ` Tassilo Horn
  2010-07-30 20:46                 ` Wojciech Meyer
  2010-07-30 21:48                 ` Stefan Monnier
  0 siblings, 2 replies; 16+ messages in thread
From: Tassilo Horn @ 2010-07-30 20:08 UTC (permalink / raw)
  To: Wojciech Meyer; +Cc: Johan Bockgård, emacs-devel

On Friday 30 July 2010 21:54:15 Wojciech Meyer wrote:
> Tassilo Horn <tassilo@member.fsf.org>  writes:
> 
> > IMO a function shouldn't need to allow modification of it's return
> > value explicitly, but instead should warn if that's possible.  But
> > indeed, evaluating
> >
> >   (aset (buffer-name) 0 ?g)
> 
> How would you do this? I see that the check can be performed on only
> at runtime. Bytecompiler will not warn, because the value might be
> propagated, and Lisp is dynamicaly typed. (in simple cases like this
> it is apparent, but consider just returning this value from function).

No no, you got me wrong.  I just meant the docstring of `buffer-name'
(and any other function that returns some thing whose modification would
have undesired, non-obvious side-effects) should explicitly state that
modifying that returned string will indeed modify the buffer name.

Johan argued the other way round, that it's clear that you should not do
that because the function doesn't explicitly state that the returned
string is a fresh copy.

Bye,
Tassilo



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

* Re: Buffer names are sometimes read-only objects in daemonized emacs
  2010-07-30 20:08               ` Tassilo Horn
@ 2010-07-30 20:46                 ` Wojciech Meyer
  2010-07-30 21:48                 ` Stefan Monnier
  1 sibling, 0 replies; 16+ messages in thread
From: Wojciech Meyer @ 2010-07-30 20:46 UTC (permalink / raw)
  To: Tassilo Horn; +Cc: Wojciech Meyer, Johan Bockgård, emacs-devel

Tassilo Horn <tassilo@member.fsf.org> writes:

>> How would you do this? I see that the check can be performed on only
>> at runtime. Bytecompiler will not warn, because the value might be
>> propagated, and Lisp is dynamicaly typed. (in simple cases like this
>> it is apparent, but consider just returning this value from function).
>
> No no, you got me wrong.  I just meant the docstring of `buffer-name'
> (and any other function that returns some thing whose modification would
> have undesired, non-obvious side-effects) should explicitly state that
> modifying that returned string will indeed modify the buffer name.

Sry. I now got it.
The thing is that you should never modify inplace other string refs then
returned from make-string, the same applies to string literals.  e.g
text surounded by double quotes. (this could land easily in some read
only area). You could assume that all the string refs, are passed by
ref, and the string (mainly for performance reasons) will the same
object as in the buffer-list. So the advise is, modify inplace only if
you are sure it will not clobber the data in the other corner of Emacs
Also, Elisp has highly stateful nature, and it is hard to avoid such
quirks.

>
> Johan argued the other way round, that it's clear that you should not do
> that because the function doesn't explicitly state that the returned
> string is a fresh copy.

Yes, that's indeed better idea, as it will happen less often.

>
> Bye,
> Tassilo

Wojciech



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

* Re: Buffer names are sometimes read-only objects in daemonized emacs
  2010-07-30 20:08               ` Tassilo Horn
  2010-07-30 20:46                 ` Wojciech Meyer
@ 2010-07-30 21:48                 ` Stefan Monnier
  2010-07-30 22:07                   ` Lennart Borgman
  2010-07-30 23:35                   ` Johan Bockgård
  1 sibling, 2 replies; 16+ messages in thread
From: Stefan Monnier @ 2010-07-30 21:48 UTC (permalink / raw)
  To: Tassilo Horn; +Cc: Wojciech Meyer, Bockgård, emacs-devel

> No no, you got me wrong.  I just meant the docstring of `buffer-name'
> (and any other function that returns some thing whose modification would
> have undesired, non-obvious side-effects) should explicitly state that
> modifying that returned string will indeed modify the buffer name.

Rather, `aset' should warn that modifying strings is evil and dangerous.


        Stefan "whose aset refuses to do it"



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

* Re: Buffer names are sometimes read-only objects in daemonized emacs
  2010-07-30 21:48                 ` Stefan Monnier
@ 2010-07-30 22:07                   ` Lennart Borgman
  2010-08-01 23:09                     ` Stefan Monnier
  2010-07-30 23:35                   ` Johan Bockgård
  1 sibling, 1 reply; 16+ messages in thread
From: Lennart Borgman @ 2010-07-30 22:07 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

On Fri, Jul 30, 2010 at 11:48 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> No no, you got me wrong.  I just meant the docstring of `buffer-name'
>> (and any other function that returns some thing whose modification would
>> have undesired, non-obvious side-effects) should explicitly state that
>> modifying that returned string will indeed modify the buffer name.
>
> Rather, `aset' should warn that modifying strings is evil and dangerous.
>
>
>        Stefan "whose aset refuses to do it"


When will this aset be grown up enough to play outside of home?



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

* Re: Buffer names are sometimes read-only objects in daemonized emacs
  2010-07-30 21:48                 ` Stefan Monnier
  2010-07-30 22:07                   ` Lennart Borgman
@ 2010-07-30 23:35                   ` Johan Bockgård
  2010-08-01 23:10                     ` Stefan Monnier
  1 sibling, 1 reply; 16+ messages in thread
From: Johan Bockgård @ 2010-07-30 23:35 UTC (permalink / raw)
  To: emacs-devel

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

>> No no, you got me wrong.  I just meant the docstring of `buffer-name'
>> (and any other function that returns some thing whose modification would
>> have undesired, non-obvious side-effects) should explicitly state that
>> modifying that returned string will indeed modify the buffer name.
>
> Rather, `aset' should warn that modifying strings is evil and dangerous.

Should `put-text-property' do that too?



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

* Re: Buffer names are sometimes read-only objects in daemonized emacs
  2010-07-30 22:07                   ` Lennart Borgman
@ 2010-08-01 23:09                     ` Stefan Monnier
  0 siblings, 0 replies; 16+ messages in thread
From: Stefan Monnier @ 2010-08-01 23:09 UTC (permalink / raw)
  To: Lennart Borgman; +Cc: emacs-devel

>>> No no, you got me wrong.  I just meant the docstring of `buffer-name'
>>> (and any other function that returns some thing whose modification would
>>> have undesired, non-obvious side-effects) should explicitly state that
>>> modifying that returned string will indeed modify the buffer name.
>> Rather, `aset' should warn that modifying strings is evil and dangerous.
> When will this aset be grown up enough to play outside of home?

Never (as in "not for the foreseeable future"),  It would not bring any
benefit to the users, and would break backward compatibility: sound like
a clear loser to me.


        Stefan



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

* Re: Buffer names are sometimes read-only objects in daemonized emacs
  2010-07-30 23:35                   ` Johan Bockgård
@ 2010-08-01 23:10                     ` Stefan Monnier
  0 siblings, 0 replies; 16+ messages in thread
From: Stefan Monnier @ 2010-08-01 23:10 UTC (permalink / raw)
  To: emacs-devel

>>> No no, you got me wrong.  I just meant the docstring of `buffer-name'
>>> (and any other function that returns some thing whose modification would
>>> have undesired, non-obvious side-effects) should explicitly state that
>>> modifying that returned string will indeed modify the buffer name.
>> Rather, `aset' should warn that modifying strings is evil and dangerous.
> Should `put-text-property' do that too?

Probably, but that will break a lot more packages (removing the "aset on
strings" feature breaks fairly few packages, surprisingly enough).


        Stefan



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

end of thread, other threads:[~2010-08-01 23:10 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-07-29 20:30 How do I debug errors in post-command-hook? Tassilo Horn
2010-07-29 21:33 ` Lennart Borgman
2010-07-30  0:11 ` Johan Bockgård
2010-07-30  6:54   ` Tassilo Horn
2010-07-30 11:58     ` Johan Bockgård
2010-07-30 14:23       ` Buffer names are sometimes read-only objects in daemonized emacs (was: How do I debug errors in post-command-hook?) Tassilo Horn
2010-07-30 17:46         ` Buffer names are sometimes read-only objects in daemonized emacs Johan Bockgård
2010-07-30 18:41           ` Tassilo Horn
2010-07-30 19:54             ` Wojciech Meyer
2010-07-30 20:08               ` Tassilo Horn
2010-07-30 20:46                 ` Wojciech Meyer
2010-07-30 21:48                 ` Stefan Monnier
2010-07-30 22:07                   ` Lennart Borgman
2010-08-01 23:09                     ` Stefan Monnier
2010-07-30 23:35                   ` Johan Bockgård
2010-08-01 23:10                     ` Stefan Monnier

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.