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
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