Fix a few issues with the Emacs mode definition.
First, in 1ab7789f3 (2021-10-13, Emacs: Protobuf mode should be derived from
prog-mode) we made `protobuf-mode' a derived mode of `prog-mode' using the
`define-derived-mode' macro[1]. However, the definition body was not updated
accordingly. So in this commit, we:
- Remove the superfluous `(interactive)' form;
- Remove the unnecessary call of `kill-all-local-variables', which is already
handled by `define-derived-mode' and could cause a few issues, for example,
it prevents `prog-mode-hook' from being run;
- Remove forms that set `major-mode' and `mode-name', which are automatically
set to the first and third arguments respectively;
- Remove forms that set key map, syntax table, and abbrev table, which are
already handled automatically;
- Do not run `protobuf-mode-hook' explicitly in the body. It is already arranged
to be run after the body.
Second, the call to `c-make-emacs-variables-local' is removed. It is called
inside `c-init-language-vars' already. Calling it again should do no harm now,
but to be future-proof it might be better to just remove it.
Finally, we move the `c-update-modeline' form to the :after-hook argument to
ensure it is run at the very end, so that the mode line will reflect all user
customizations done in various mode hooks. Similarly, we run
`c-mode-common-hook' also at the very end to leave a place for user
customizations (for example, set `imenu-generic-expression' in
`c-mode-common-hook').
[1] https://www.gnu.org/software/emacs/manual/html_node/elisp/Derived-Modes.html
Re: https://github.com/protocolbuffers/protobuf/issues/7316
Re: https://github.com/protocolbuffers/protobuf/pull/9076
Requiring the legacy ‘cl’ library unconditionally pollutes the namespace.
Instead, require it only when compiling and in known-broken versions.
This is almost the same patch that opoplawski suggested, except that I removed
the test for ‘emacs-repository-version’, which isn’t defined in Emacs 24.3.
General
* License changed from Apache 2.0 to New BSD.
* It is now possible to define custom "options", which are basically
annotations which may be placed on definitions in a .proto file.
For example, you might define a field option called "foo" like so:
import "google/protobuf/descriptor.proto"
extend google.protobuf.FieldOptions {
optional string foo = 12345;
}
Then you annotate a field using the "foo" option:
message MyMessage {
optional int32 some_field = 1 [(foo) = "bar"]
}
The value of this option is then visible via the message's
Descriptor:
const FieldDescriptor* field =
MyMessage::descriptor()->FindFieldByName("some_field");
assert(field->options().GetExtension(foo) == "bar");
This feature has been implemented and tested in C++ and Java.
Other languages may or may not need to do extra work to support
custom options, depending on how they construct descriptors.
C++
* Fixed some GCC warnings that only occur when using -pedantic.
* Improved static initialization code, making ordering more
predictable among other things.
* TextFormat will no longer accept messages which contain multiple
instances of a singular field. Previously, the latter instance
would overwrite the former.
* Now works on systems that don't have hash_map.
Python
* Strings now use the "unicode" type rather than the "str" type.
String fields may still be assigned ASCII "str" values; they will
automatically be converted.
* Adding a property to an object representing a repeated field now
raises an exception. For example:
# No longer works (and never should have).
message.some_repeated_field.foo = 1
Hong Shin
Benjamin Peterson
Adam Cozzette
kunhtkun
Hong Xu
Jimmy Yuen Ho Wong
lakshayg
Joshua Haberman
Yue Zhu
Evan Klitzke
listonjesse
Philipp Stephani
Yutian Li
Bo Yang
Nobuaki Sukegawa
Feng Xiao
liujisi@google.com
kenton@google.com
Jon Skeet
temporal