Re: [Bug-AUCTeX] Re: 2005-06-15; wrong-type-argument with LaTeX-includegraphics-read-file-relative

[David Kastrup]

Ralf Angeli <address@hidden> writes:

> * David Kastrup (2005-06-16) writes:
>
>> Ralf Angeli <address@hidden> writes:
>>
>>> * Franz Haeuslschmid (2005-06-16) writes:
>>>
>>>> Anyway, as I prepared the report, it stroke me,
>>>> that the process of inserting macros is not transactional.
> [...]
>>> Doing this currently would be tricky.  The code for inserting macros
>>> inserts the plain macro and then calls potential special functions for
>>> inserting arguments of the macro.  In case processing of these special
>>> functions is aborted, the plain macro will remain in the buffer as you
>>> observed.
>>
>> Emacs CVS has
>>
>> atomic-change-group is a Lisp macro in `subr'.
>> (atomic-change-group &rest BODY)
>>
>> Perform BODY as an atomic change group.
>
> Interesting.  Now the question is if we actually want to have this
> behavior.

I think that in most cases I'd prefer not to have it.  I can always
roll back with C-/ myself.

> As an example, I often abort the insertion of labels when adding a
> sectioning command and would not want to have everything rolled back
> in this case.  But this mostly occurs when I am testing stuff and
> not during normal writing, so this might not be representative.
>
> But we are not (yet) talking about `LaTeX-section' but about
> `TeX-insert-macro'.  Currently I don't have an example where it
> could be useful to abort the insertion and be happy with the
> inserted plain macro.  So it would be fine with me.  What about
> other people?

I think that we should rather try to have the buffer in reasonable
intermediate states when prompts come up, so that C-g does not leave
them more inconvenient than necessary.  And if people don't want to do
the arguments in the AUCTeX way, we should not sulk and say "ok, you
don't get anything then".

> In case we want that, I could check in the attached patch.  (That's
> actually the first macro I've ever written.  Nobody tell me that
> this would be better done with something like defalias or
> defun. (c;)

Macros not in need of being special are more often than not
conveniently written using defsubst.  I have not actually taken a look
whether this applies here because I don't think it a really good idea,
anyway.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum