unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: MON KEY <monkey@sandpframing.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 6525@debbugs.gnu.org
Subject: bug#6525: documentation of macro `with-silent-modifications' 1 typo + multi-horrid
Date: Thu, 1 Jul 2010 19:07:14 -0400	[thread overview]
Message-ID: <AANLkTikOLbO59lc2pRshUyuLIxqdvzEmwRKz_1wwcBb_@mail.gmail.com> (raw)
In-Reply-To: <jwv8w5w3tbo.fsf-monnier+emacs@gnu.org>

On Wed, Jun 30, 2010 at 9:10 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:

>> ,---- (documentation 'with-silent-modifications)
>> |
>> | "Execute BODY, pretending it does not modifies the buffer.
>> | If BODY performs real modifications to the buffer's text, other than
>> | cosmetic ones, undo data may become corrupted.  Typically used
>> | around modifications of text-properties which do not really affect
>> | the buffer's content."
>> |
>> `----

> Docstrings should generally only document what the function/macro
> does, rather than how they're used.  So the "typical uses" I put
> here is actually a bad idea, tho it was just easier to do that than
> to try and describe what the macro does, {...}

Indeed, this may be so, but it certainly isn't any easier for me to
understand what it does.

I absolutely can not understand what is meant by the docstring.

Though, really, I typically do pretend at understanding these types of
things unless the content is not other than cosmetic such that it can
not perform any real modifications affecting my perspective of these
things :-P

> I don't know what atypical uses might be, and don't care about them

If it has typical usage then it has atypical usage. Presumably that
the macro exists suggests that there is a typical usage.  The macro
would go away if it didn't have a typical usage. That it doesn't
suggests  _someone_ cares about partitioning the typical from the
atypical usage whether you do or not.

If such usage is typical enough so as to support creation of the macro
it would seem reasonable to expect a resasonable documentation of what
it should be expected to do -- and, it should say so without over
reliance on vacuous terms like `pretending', `really', `typically',
`cosmetic', `real modifications', `content' etc.

> (at least until they come complaining about some undesirable part of
> the behavior).

Thats a nice long rope you've given users.
Maybe they get lost at the outer regions of that tether in which case
they aren't likely to come complaining...

What behaviour would you expect them to complain about if they can not
deduce from the docstring what it is they should expect this macro to
do?

>> around modifications of text-properties which do not really affect
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^|^^^^^^^^^^^^^^^^^^^^^^^^^
>>                          what is the affector txt-prop or the mod?
>
> Some other code: the caller would presumably know.

How could a caller modify text-properties which do not _really_ affect
the buffer? They either do affect whehter the buffer is modified or
they don't.

More precisely, what are the text-properties that do not _really_
affect a/the buffer?

>> the buffer's content.
>> ^^^^^^^^^^^^^|^^^^^^
>>    exactly what _is_ content - chars, tps, overlays, fields, faces?
>
> Can be any of it, depending on the case, because it's a conceptual

Whose conceptual notion, the callers, yours, or Emacs' vis a vis
`buffer-modified-p'?

> notion, rather than a technical one: typically "modify the buffer's
> content" means "saving the buffer results in a different file".

The use of `content' here is not good. The term is too "conceptually"
overloaded to be of any use in the context of which it is used.

>        Stefan

---
/s_P





  reply	other threads:[~2010-07-01 23:07 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-28  7:36 bug#6525: documentation of macro `with-silent-modifications' 1 typo + multi-horrid MON KEY
2010-07-01  1:10 ` Stefan Monnier
2010-07-01 23:07   ` MON KEY [this message]
2010-07-04 17:21     ` bug#6525: documentation of macro `with-silent-modifications' 1 Stefan Monnier
2010-07-06 21:29       ` MON KEY
2011-07-13 23:40       ` Lars Magne Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AANLkTikOLbO59lc2pRshUyuLIxqdvzEmwRKz_1wwcBb_@mail.gmail.com \
    --to=monkey@sandpframing.com \
    --cc=6525@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).