[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#19178: closed (Re: bug#19178: 11.88; 11.88 Xemacs 11.88 problem with
From: |
Mosè Giordano |
Subject: |
bug#19178: closed (Re: bug#19178: 11.88; 11.88 Xemacs 11.88 problem with env and labels) |
Date: |
Wed, 26 Nov 2014 19:49:46 +0100 |
> - ""))))
> + ""))
> + ((nullp type)
> + "")))
^^^^
Sorry, I meant nil instead of ""
2014-11-26 19:45 GMT+01:00 Mosè Giordano <address@hidden>:
> 2014-11-26 12:57 GMT+01:00 Uwe Brauer <address@hidden>:
>>
>> Hi Mosè
>> > Hi Uwe,
>> > 2014-11-25 18:48 GMT+01:00 Uwe Brauer <address@hidden>:
>>
>> > I agree backward compatibility should be preserved as long as possible
>> > (but not at any cost), but about what? Most users only customize
>> > variables, don't fiddle with functions, if they write some elisp we
>> > hope they're also able to read the doc string of a function and see
>> > which are its arguments, if they've been changed. But please consider
>> > the first version of a program (nor the second, the third, and so on)
>> > is not perfect, when you develop it you arrive at a point in which you
>> > must choose between keeping it bugged/broken, and fix it and break
>> > compatibility (or fork it).
>>
>> My point is the following: if you improve a function or variable by
>> adding more options it should be done, in my opinion, in way the user
>> has not to change his old settings.
>>
>> > Regarding the change to `LaTeX-label', the whole point of it was to
>> > let users choose to which environments label should be inserted. The
>> > addition of the second argument was needed to discriminate between
>> > environments and sections as suggested by Vladimir.
>>
>> I don't want to start this discussion again, since I also use reftex,
>> my labels look typically
>>
>> \label{rem:fixpoint-scheme:2}
>>
>> Meaning that this is the second remark in the file called fixpoint-scheme.
>> For
>> me this is enough I wouldn't need to add more information like the one
>> concerning the section, but I understand there are users with other needs.
>>
>>
>> > Defaulting `prefix' to an empty string when no type is provided (in
>> > order to make this argument optional) would defeat the whole
>> > purpose of the change. Only defaulting `prefix' to nil wouldn't
>> > break old codes using `LateX-label' function, but keeping the
>> > second argument mandatory helps users be aware of the change of the
>> > syntax of `LaTeX-label'.
>>
>> I had a look at the code and it is really a complete rewrite. From my
>> philosophical point of view, the "appropriate" approach would have been
>> to leave the second argument optionally not mandatory, and a user
>> interested in this enhancement could consult the documentation and not
>> the other way around: that the long-term-user gets an error and presumes
>> a bug.
>>
>> Something like this.
>> (defun LaTeX-label (name &optional type)
>>
>>
>> > Moral: I'm not going to change `LaTeX-label'.
>>
>> Would you accept an (ugly) patch? (Also the changes that I do this any
>> time soon are unlikely due to my workload and other priorities, such as
>> the xemacs pkg sync.)
>
> See the attached patch: this makes second argument optional but
> doesn't change the spirit of LaTeX-label.
>
> Bye,
> Mosè
- [Bug-AUCTeX] bug#19178: closed (Re: bug#19178: 11.88; 11.88 Xemacs 11.88 problem with env and labels), (continued)
- [Bug-AUCTeX] bug#19178: [no label inserted] (was: bug#19178: 11.88; 11.88 Xemacs 11.88 problem with env and labels), Uwe Brauer, 2014/11/25
- bug#19178: [no label inserted] (was: bug#19178: 11.88; 11.88 Xemacs 11.88 problem with env and labels), Mosè Giordano, 2014/11/25
- bug#19178: closed (Re: bug#19178: 11.88; 11.88 Xemacs 11.88 problem with env and labels), Mosè Giordano, 2014/11/25
- bug#19178: closed (Re: bug#19178: 11.88; 11.88 Xemacs 11.88 problem with env and labels), Uwe Brauer, 2014/11/25
- bug#19178: [no label inserted], Uwe Brauer, 2014/11/25
- bug#19178: closed (Re: bug#19178: 11.88; 11.88 Xemacs 11.88 problem with env and labels), Uwe Brauer, 2014/11/26
- bug#19178: closed (Re: bug#19178: 11.88; 11.88 Xemacs 11.88 problem with env and labels), Uwe Brauer, 2014/11/27
- bug#19178: closed (Re: bug#19178: 11.88; 11.88 Xemacs 11.88 problem with env and labels), Uwe Brauer, 2014/11/27
- bug#19178: closed (Re: bug#19178: 11.88; 11.88 Xemacs 11.88 problem with env and labels), Uwe Brauer, 2014/11/27