* Derived modes and mode hooks @ 2013-03-09 14:06 Sebastian Wiesner 2013-03-09 14:31 ` Xue Fuqiao 2013-03-09 15:56 ` Stefan Monnier 0 siblings, 2 replies; 14+ messages in thread From: Sebastian Wiesner @ 2013-03-09 14:06 UTC (permalink / raw) To: emacs-devel Hello, if I understand the documentation of derived modes [1] aright, *all* hooks (including parent mode hooks) are run *after* the body of the derived mode. For instance, given "foo-mode" defined as: (define-derived-mode foo-mode text-mode "Foo" "A useless mode for demonstration purposes" (body-of-foo-mode)) Then "M-x foo-mode" will 1. Perform some standard setup stuff (e.g. killing local variables, setting the key map, etc.) 2. Execute "body-of-foo-mode" 3. Execute all hooks in "text-mode-hook" 4. Execute all hooks in "foo-mode-hook" Is this right? If so, how can `body-of-foo-mode` forcibly overrule settings made in `text-mode-hook`? For instance, assume that the user has "(add-hook 'text-mode-hook 'auto-fill-mode)" in her init file (a very common setting I presume), how can "foo-mode" "body-of-foo-mode" forcibly disable "auto-fill-mode"? Greetings, Sebastian Wiesner [1]: http://www.gnu.org/software/emacs/manual/html_node/elisp/Derived-Modes.html ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Derived modes and mode hooks 2013-03-09 14:06 Derived modes and mode hooks Sebastian Wiesner @ 2013-03-09 14:31 ` Xue Fuqiao 2013-03-09 14:43 ` Sebastian Wiesner 2013-03-09 15:56 ` Stefan Monnier 1 sibling, 1 reply; 14+ messages in thread From: Xue Fuqiao @ 2013-03-09 14:31 UTC (permalink / raw) To: Sebastian Wiesner; +Cc: emacs-devel On Sat, 9 Mar 2013 15:06:00 +0100 Sebastian Wiesner <lunaryorn@gmail.com> wrote: > For instance, given "foo-mode" defined as: > > (define-derived-mode foo-mode text-mode "Foo" > "A useless mode for demonstration purposes" > (body-of-foo-mode)) > Then "M-x foo-mode" will > 1. Perform some standard setup stuff (e.g. killing local variables, > setting the key map, etc.) > 2. Execute "body-of-foo-mode" > 3. Execute all hooks in "text-mode-hook" > 4. Execute all hooks in "foo-mode-hook" > Is this right? If so, how can `body-of-foo-mode` forcibly overrule > settings made in `text-mode-hook`? See the function `run-mode-hooks'. I'm no expert on this, but IIRC `after-change-major-mode-hook' helps. -- Best regards, Xue Fuqiao. http://www.emacswiki.org/emacs/XueFuqiao ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Derived modes and mode hooks 2013-03-09 14:31 ` Xue Fuqiao @ 2013-03-09 14:43 ` Sebastian Wiesner 0 siblings, 0 replies; 14+ messages in thread From: Sebastian Wiesner @ 2013-03-09 14:43 UTC (permalink / raw) To: Xue Fuqiao; +Cc: emacs-devel 2013/3/9 Xue Fuqiao <xfq.free@gmail.com>: > On Sat, 9 Mar 2013 15:06:00 +0100 > Sebastian Wiesner <lunaryorn@gmail.com> wrote: > >> For instance, given "foo-mode" defined as: >> >> (define-derived-mode foo-mode text-mode "Foo" >> "A useless mode for demonstration purposes" >> (body-of-foo-mode)) > >> Then "M-x foo-mode" will > >> 1. Perform some standard setup stuff (e.g. killing local variables, >> setting the key map, etc.) >> 2. Execute "body-of-foo-mode" >> 3. Execute all hooks in "text-mode-hook" >> 4. Execute all hooks in "foo-mode-hook" > >> Is this right? If so, how can `body-of-foo-mode` forcibly overrule >> settings made in `text-mode-hook`? > > See the function `run-mode-hooks'. What am I supposed to see there? I read the documentation of this function, even looked at its source code, and now I feel confirmed in my analysis of things. But I can't see anything that would help me to solve the actual problem, that is forcibly disabling `auto-fill-mode`. I can't even control when and how this function is invoked, as `define-derived-mode` does that implicitly. > I'm no expert on this, but IIRC `after-change-major-mode-hook' helps. Call me stupid, but I fail to see how it could. It's executed even earlier than `body-of-foo-mode`, and thus suffers from the same problem: The later execution of `text-mode-hook` will bring back `auto-fill-mode`, given `(add-hook 'text-mode-hook 'auto-fill-mode)` in the user's init file. I need something that runs *after* `text-mode-hook`, but *before* `foo-mode-hook`. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Derived modes and mode hooks 2013-03-09 14:06 Derived modes and mode hooks Sebastian Wiesner 2013-03-09 14:31 ` Xue Fuqiao @ 2013-03-09 15:56 ` Stefan Monnier 2013-03-09 16:25 ` Sebastian Wiesner 1 sibling, 1 reply; 14+ messages in thread From: Stefan Monnier @ 2013-03-09 15:56 UTC (permalink / raw) To: Sebastian Wiesner; +Cc: emacs-devel > Is this right? If so, how can `body-of-foo-mode` forcibly overrule > settings made in `text-mode-hook`? It can't (well, if it really really wants to, it can add some code to its own foo-mode-hook which is run after text-mode-hook). A function added to a mode hook takes precedence, because it's presumably a user choice, whereas body-of-foo-mode is the choice of code's author. If the user doesn't want auto-fill-mode in foo-mode, she can add to foo-mode-hook to turn auto-fill-mode off, or she can change her text-mode-hook to test (derived-mode-p 'foo-mode) before enabling auto-fill-mode. Stefan ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Derived modes and mode hooks 2013-03-09 15:56 ` Stefan Monnier @ 2013-03-09 16:25 ` Sebastian Wiesner 2013-03-09 16:43 ` Eli Zaretskii 2013-03-10 5:53 ` Stefan Monnier 0 siblings, 2 replies; 14+ messages in thread From: Sebastian Wiesner @ 2013-03-09 16:25 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 2013/3/9 Stefan Monnier <monnier@iro.umontreal.ca>: > It can't (well, if it really really wants to, it can add some code to > its own foo-mode-hook which is run after text-mode-hook). That's unfortunate. > A function added to a mode hook takes precedence, because it's presumably > a user choice, whereas body-of-foo-mode is the choice of code's author. I can understand the rationale for this design, but I find it too limited: A *more specific* mode cannot overrule the customization of *more generic* modes, even if the customization for the generic mode doesn't make sense, or is even dangerous, in the more specific mode. To give a concrete example for such a case: The phpbb forum software translates line breaks in the BB Code markup of posts into line breaks in the HTML rendering, i.e. line breaks in the markup of a posting directly affect its visual representation. Hence, automatic filling is a no-go, and I want to disable by default in this mode, even if the user has enabled it generically by the common way of adding it to "text-mode-hook". I cannot do so now, but instead have to burden the user with the responsibility to get the customization right for my mode. To the user this means that one cannot simply enable auto filling generically for all text modes and be on the safe side. Instead she has to check whether the mode works well with auto filling, and maintain an explicit black- or whitelist in her Init file, which is rather cumbersome imho. > If the user doesn't want auto-fill-mode in foo-mode, she can add to > foo-mode-hook to turn auto-fill-mode off, or she can change her > text-mode-hook to test (derived-mode-p 'foo-mode) before enabling > auto-fill-mode. I am not talking about users here, I am talking about the needs of major mode *authors*, who may wish to disable dangerous settings in their modes, even if that includes overruling some of the user's customizations for *more generic* modes. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Derived modes and mode hooks 2013-03-09 16:25 ` Sebastian Wiesner @ 2013-03-09 16:43 ` Eli Zaretskii 2013-03-09 17:03 ` Sebastian Wiesner 2013-03-10 5:53 ` Stefan Monnier 1 sibling, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2013-03-09 16:43 UTC (permalink / raw) To: Sebastian Wiesner; +Cc: monnier, emacs-devel > Date: Sat, 9 Mar 2013 17:25:09 +0100 > From: Sebastian Wiesner <lunaryorn@gmail.com> > Cc: emacs-devel <emacs-devel@gnu.org> > > To give a concrete example for such a case: The phpbb forum software > translates line breaks in the BB Code markup of posts into line breaks > in the HTML rendering, i.e. line breaks in the markup of a posting > directly affect its visual representation. Hence, automatic filling > is a no-go, and I want to disable by default in this mode, even if the > user has enabled it generically by the common way of adding it to > "text-mode-hook". See fill-nobreak-predicate. You can use that, and then automatic filling will work correctly for HTML. > I cannot do so now, but instead have to burden the user with the > responsibility to get the customization right for my mode. No, you don't, see above. > > If the user doesn't want auto-fill-mode in foo-mode, she can add to > > foo-mode-hook to turn auto-fill-mode off, or she can change her > > text-mode-hook to test (derived-mode-p 'foo-mode) before enabling > > auto-fill-mode. > > I am not talking about users here, I am talking about the needs of > major mode *authors*, who may wish to disable dangerous settings in > their modes, even if that includes overruling some of the user's > customizations for *more generic* modes. It is not any bloody business of a mode author to override customizations of users. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Derived modes and mode hooks 2013-03-09 16:43 ` Eli Zaretskii @ 2013-03-09 17:03 ` Sebastian Wiesner 2013-03-09 17:51 ` Eli Zaretskii 0 siblings, 1 reply; 14+ messages in thread From: Sebastian Wiesner @ 2013-03-09 17:03 UTC (permalink / raw) To: Eli Zaretskii; +Cc: monnier, emacs-devel 2013/3/9 Eli Zaretskii <eliz@gnu.org>: >> Date: Sat, 9 Mar 2013 17:25:09 +0100 >> From: Sebastian Wiesner <lunaryorn@gmail.com> >> Cc: emacs-devel <emacs-devel@gnu.org> >> >> To give a concrete example for such a case: The phpbb forum software >> translates line breaks in the BB Code markup of posts into line breaks >> in the HTML rendering, i.e. line breaks in the markup of a posting >> directly affect its visual representation. Hence, automatic filling >> is a no-go, and I want to disable by default in this mode, even if the >> user has enabled it generically by the common way of adding it to >> "text-mode-hook". > > See fill-nobreak-predicate. You can use that, and then automatic > filling will work correctly for HTML. In order to completely disable automatic filling I'd add a function which simply returns t to this list? That sounds like a nasty hack to me. Also this only handles the case of auto-fill-mode… By the way, I did not talk about filling HTML, but I guess it just wasn't your “bloody business” to read my mail carefully, was it? >> > If the user doesn't want auto-fill-mode in foo-mode, she can add to >> > foo-mode-hook to turn auto-fill-mode off, or she can change her >> > text-mode-hook to test (derived-mode-p 'foo-mode) before enabling >> > auto-fill-mode. >> >> I am not talking about users here, I am talking about the needs of >> major mode *authors*, who may wish to disable dangerous settings in >> their modes, even if that includes overruling some of the user's >> customizations for *more generic* modes. > > It is not any bloody business of a mode author to override > customizations of users. I'm talking overriding customization *in the special case*, that a customization for a *parent mode* (which the user most likely did without caring for, or even knowing of, a specific derived mode) is *not reasonably applicable* in a derived mode, for the sake of convenience for the users of the derived mode. But please ignore this objection of mine, I rather thank you wholeheartedly for ignoring this specific special case and instead giving me the perfect excuse of an Emacs authority stating that it's not my “bloody business” to care for my user's needs. In case any user of my mode foolishly fails to understand this special notion of Emacs development, may I forward her to your mail address, for special guidance on the latest and greatest Emacs development practices? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Derived modes and mode hooks 2013-03-09 17:03 ` Sebastian Wiesner @ 2013-03-09 17:51 ` Eli Zaretskii 2013-03-09 18:58 ` Sebastian Wiesner 0 siblings, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2013-03-09 17:51 UTC (permalink / raw) To: Sebastian Wiesner; +Cc: monnier, emacs-devel > Date: Sat, 9 Mar 2013 18:03:17 +0100 > From: Sebastian Wiesner <lunaryorn@gmail.com> > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > > 2013/3/9 Eli Zaretskii <eliz@gnu.org>: > >> Date: Sat, 9 Mar 2013 17:25:09 +0100 > >> From: Sebastian Wiesner <lunaryorn@gmail.com> > >> Cc: emacs-devel <emacs-devel@gnu.org> > >> > >> To give a concrete example for such a case: The phpbb forum software > >> translates line breaks in the BB Code markup of posts into line breaks > >> in the HTML rendering, i.e. line breaks in the markup of a posting > >> directly affect its visual representation. Hence, automatic filling > >> is a no-go, and I want to disable by default in this mode, even if the > >> user has enabled it generically by the common way of adding it to > >> "text-mode-hook". > > > > See fill-nobreak-predicate. You can use that, and then automatic > > filling will work correctly for HTML. > > In order to completely disable automatic filling I'd add a function > which simply returns t to this list? That's one possibility; I'm sure there are others, less radical ones. > That sounds like a nasty hack to me. I don't see why. It is certainly not as nasty as overriding user customizations. > Also this only handles the case of auto-fill-mode… You gave an example of a problem, I gave you an example of a solution. My point being that there should be a similar solution for each such problem. IOW, someone already bumped into the same problems, and provided solutions. You just need to find them. (And I'm not too smart in this matter: I just looked in sgml.el.) > By the way, I did not talk about filling HTML, but I guess it just > wasn't your “bloody business” to read my mail carefully, was it? I did read it, I just didn't understand it in full. You were talking about modes I know nothing about; you cannot expect me to study every reference in what you say just to show how the same problems could be solved differently. > > It is not any bloody business of a mode author to override > > customizations of users. > > I'm talking overriding customization *in the special case*, that a > customization for a *parent mode* (which the user most likely did > without caring for, or even knowing of, a specific derived mode) is > *not reasonably applicable* in a derived mode, for the sake of > convenience for the users of the derived mode. The whole business of inheriting from a mode makes sense only when the child mode is compatible with its parent. If this is not so in too many levels, then inheriting for such a parent is not what you want. If a small number of user customizations don't make any sense in the child mode, then using variables such as fill-nobreak-predicate is _the_ way, and users will not blame you, because they understand why e.g. filling makes no sense in some situations in your mode. But futzing with user customizations _directly_, i.e. by changing them, is a no-no in any case, IMO. > But please ignore this objection of mine, I rather thank you > wholeheartedly for ignoring this specific special case and instead > giving me the perfect excuse of an Emacs authority stating that it's > not my “bloody business” to care for my user's needs. That's not what I said (there's nothing about "user's needs" in my wording), but whatever. > In case any user of my mode foolishly fails to understand this > special notion of Emacs development, may I forward her to your mail > address, for special guidance on the latest and greatest Emacs > development practices? Feel free. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Derived modes and mode hooks 2013-03-09 17:51 ` Eli Zaretskii @ 2013-03-09 18:58 ` Sebastian Wiesner 2013-03-09 19:31 ` Eli Zaretskii 0 siblings, 1 reply; 14+ messages in thread From: Sebastian Wiesner @ 2013-03-09 18:58 UTC (permalink / raw) To: Eli Zaretskii; +Cc: monnier, emacs-devel 2013/3/9 Eli Zaretskii <eliz@gnu.org>: >> In order to completely disable automatic filling I'd add a function >> which simply returns t to this list? > > That's one possibility; I'm sure there are others, less radical ones. > >> That sounds like a nasty hack to me. > > I don't see why. It is certainly not as nasty as overriding user > customizations. So your proposed solution effectively inhibits auto filling and thus also *effectively overrides* the user's customization, but in a convoluted way, abusing a variable which is obviously intended for a different purpose, and which most likely only few users even know about. Yet you actually *prefer* this crude way of effectively overriding the user's customization over simply disabling the mode, *the* obvious way of inhibiting auto filling, more over clearly indicated to the user by the absence of the corresponding entry in the mode line. Did I get that correctly? >> > It is not any bloody business of a mode author to override >> > customizations of users. >> >> I'm talking overriding customization *in the special case*, that a >> customization for a *parent mode* (which the user most likely did >> without caring for, or even knowing of, a specific derived mode) is >> *not reasonably applicable* in a derived mode, for the sake of >> convenience for the users of the derived mode. > > The whole business of inheriting from a mode makes sense only when the > child mode is compatible with its parent. I wonder how you define “compatible”, for I cannot see any applicable definition of this term that would make plain "text-mode" and an advanced mode like AUCTeX' "latex-mode" “compatible”. They behave completely different, and I doubt that any *user* of AUCTeX would actually call them “compatible”. I hitherto thought the main point of derived modes was simply to allow re-use of code, and to provide a generic interface for customization, i.e. save the user the PITA of enabling auto-fill-mode explicitly in any plain text mode again. Incidentally, the latter is the only reason for deriving modes I could actually find in the Emacs Lisp manual. See "Basic Major Modes": “As far as possible, new major modes should be derived, either directly or indirectly, from one of these three modes. One reason is that this allows users to customize a single mode hook (e.g., `prog-mode-hook') for an entire family of relevant modes (e.g., all programming language modes).” Note that there are no other reasons given, following this “one reason”. Moreover neither this node, nor "Derived Modes" claim that a derived mode is supposed to be compatible to its parent mode. > If this is not so in too many levels, then inheriting for such a parent is not what you want. > If a small number of user customizations don't make any sense in the > child mode, then using variables such as fill-nobreak-predicate is > _the_ way, and users will not blame you, because they understand why > e.g. filling makes no sense in some situations in your mode. > > But futzing with user customizations _directly_, i.e. by changing > them, is a no-no in any case, IMO. I do not want to *change* the user's customization. The user's customization will still be in effect, where it makes sense, i.e. in other modes derived from text-mode. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Derived modes and mode hooks 2013-03-09 18:58 ` Sebastian Wiesner @ 2013-03-09 19:31 ` Eli Zaretskii 2013-03-09 19:49 ` Sebastian Wiesner 0 siblings, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2013-03-09 19:31 UTC (permalink / raw) To: Sebastian Wiesner; +Cc: monnier, emacs-devel > Date: Sat, 9 Mar 2013 19:58:11 +0100 > From: Sebastian Wiesner <lunaryorn@gmail.com> > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > > 2013/3/9 Eli Zaretskii <eliz@gnu.org>: > >> In order to completely disable automatic filling I'd add a function > >> which simply returns t to this list? > > > > That's one possibility; I'm sure there are others, less radical ones. > > > >> That sounds like a nasty hack to me. > > > > I don't see why. It is certainly not as nasty as overriding user > > customizations. > > So your proposed solution effectively inhibits auto filling and thus > also *effectively overrides* the user's customization, but in a > convoluted way, abusing a variable which is obviously intended for a > different purpose, and which most likely only few users even know > about. > > Yet you actually *prefer* this crude way of effectively overriding the > user's customization over simply disabling the mode, *the* obvious way > of inhibiting auto filling, more over clearly indicated to the user by > the absence of the corresponding entry in the mode line. > > Did I get that correctly? No. I did say I'm sure there are less radical ways of doing this, didn't I? > > The whole business of inheriting from a mode makes sense only when the > > child mode is compatible with its parent. > > I wonder how you define “compatible”, for I cannot see any applicable > definition of this term that would make plain "text-mode" and an > advanced mode like AUCTeX' "latex-mode" “compatible”. They behave > completely different, and I doubt that any *user* of AUCTeX would > actually call them “compatible”. They are "compatible" because TeX documents are plain text documents, albeit with markup. > I hitherto thought the main point of derived modes was simply to allow > re-use of code Reuse doesn't make sense if you need to disable most of the inherited code. Might as well write your mode from scratch in that case. > I do not want to *change* the user's customization. The user's > customization will still be in effect, where it makes sense, i.e. in > other modes derived from text-mode. Customizations made to FOO-mode-hook are supposed to be in effect in any mode which inherits from FOO. In any case, you misunderstand what I meant: I meant not to modify the hook itself. It is okay to make the same effect in other ways. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Derived modes and mode hooks 2013-03-09 19:31 ` Eli Zaretskii @ 2013-03-09 19:49 ` Sebastian Wiesner 2013-03-09 20:22 ` chad 0 siblings, 1 reply; 14+ messages in thread From: Sebastian Wiesner @ 2013-03-09 19:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: monnier, emacs-devel 2013/3/9 Eli Zaretskii <eliz@gnu.org>: >> Date: Sat, 9 Mar 2013 19:58:11 +0100 >> From: Sebastian Wiesner <lunaryorn@gmail.com> >> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org >> >> 2013/3/9 Eli Zaretskii <eliz@gnu.org>: >> >> In order to completely disable automatic filling I'd add a function >> >> which simply returns t to this list? >> > >> > That's one possibility; I'm sure there are others, less radical ones. >> > >> >> That sounds like a nasty hack to me. >> > >> > I don't see why. It is certainly not as nasty as overriding user >> > customizations. >> >> So your proposed solution effectively inhibits auto filling and thus >> also *effectively overrides* the user's customization, but in a >> convoluted way, abusing a variable which is obviously intended for a >> different purpose, and which most likely only few users even know >> about. >> >> Yet you actually *prefer* this crude way of effectively overriding the >> user's customization over simply disabling the mode, *the* obvious way >> of inhibiting auto filling, more over clearly indicated to the user by >> the absence of the corresponding entry in the mode line. >> >> Did I get that correctly? > > No. I did say I'm sure there are less radical ways of doing this, > didn't I? Truly, you said so, yet the only less radical (or say, less convoluted way) I see is simply disabling the mode, which I thought you were opposing. However, we obviously misunderstood each other, see below. >> I hitherto thought the main point of derived modes was simply to allow >> re-use of code > > Reuse doesn't make sense if you need to disable most of the inherited > code. I don't indent do that. > In any case, you misunderstand what I meant: I meant not to modify the > hook itself. It is okay to make the same effect in other ways. I never meant to modify the hook itself. I agree that this is a total no-go. I merely intend to disable a specific minor mode (i.e. auto-fill-mode) in a specific major mode derived from text mode, for good reasons. I tried to do that in the body of the derived mode, only to discover that all hooks are run *after* the evaluation of the body, making my attempt pointless in face of the common way of enabling auto-fill-mode by adding it to text-mode-hook. Hence my initial mail. However, I see that there is no reasonable way to achieve this, so I'll simply tell my users to do so. Not as convenient as I had wished, but apparently the only reasonable way. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Derived modes and mode hooks 2013-03-09 19:49 ` Sebastian Wiesner @ 2013-03-09 20:22 ` chad 0 siblings, 0 replies; 14+ messages in thread From: chad @ 2013-03-09 20:22 UTC (permalink / raw) To: Sebastian Wiesner; +Cc: emacs-devel@gnu.org Development On 09 Mar 2013, at 11:49, Sebastian Wiesner <lunaryorn@gmail.com> wrote: > However, I see that there is no reasonable way to achieve this, so > I'll simply tell my users to do so. Not as convenient as I had > wished, but apparently the only reasonable way. If you're sure that auto-fill never makes sense in foo-mode, you can seed foo-mode-hook with turn-off-auto-fill (and mention such in your documentation), can't you? ~Chad ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Derived modes and mode hooks 2013-03-09 16:25 ` Sebastian Wiesner 2013-03-09 16:43 ` Eli Zaretskii @ 2013-03-10 5:53 ` Stefan Monnier 2013-03-10 15:34 ` Sebastian Wiesner 1 sibling, 1 reply; 14+ messages in thread From: Stefan Monnier @ 2013-03-10 5:53 UTC (permalink / raw) To: Sebastian Wiesner; +Cc: emacs-devel > To give a concrete example for such a case: The phpbb forum software > translates line breaks in the BB Code markup of posts into line breaks > in the HTML rendering, i.e. line breaks in the markup of a posting > directly affect its visual representation. Hence, automatic filling > is a no-go, and I want to disable by default in this mode, even if the > user has enabled it generically by the common way of adding it to > "text-mode-hook". Yes, that's unfortunate. You're going to need to be inventive in order to reconcile the fact that you want to derive from text-mode while at the same time writing a mode that behaves differently from what text-mode expects. Eli's suggestion might work, tho it's admittedly crude. Maybe you can set normal-auto-fill-function buffer-locally. Or you can set auto-fill-mode-hook buffer-locally. Or you can set the fill-column to a very large number. Or (as mentioned) you can set phpbb-mode-hook's default to disable auto-fill-mode. There are probably other options. Stefan ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Derived modes and mode hooks 2013-03-10 5:53 ` Stefan Monnier @ 2013-03-10 15:34 ` Sebastian Wiesner 0 siblings, 0 replies; 14+ messages in thread From: Sebastian Wiesner @ 2013-03-10 15:34 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 2013/3/10 Stefan Monnier <monnier@iro.umontreal.ca>: >> To give a concrete example for such a case: The phpbb forum software >> translates line breaks in the BB Code markup of posts into line breaks >> in the HTML rendering, i.e. line breaks in the markup of a posting >> directly affect its visual representation. Hence, automatic filling >> is a no-go, and I want to disable by default in this mode, even if the >> user has enabled it generically by the common way of adding it to >> "text-mode-hook". > > Yes, that's unfortunate. > > You're going to need to be inventive in order to reconcile the fact that > you want to derive from text-mode while at the same time writing a mode > that behaves differently from what text-mode expects. > > Eli's suggestion might work, tho it's admittedly crude. > Maybe you can set normal-auto-fill-function buffer-locally. > Or you can set auto-fill-mode-hook buffer-locally. > Or you can set the fill-column to a very large number. > Or (as mentioned) you can set phpbb-mode-hook's default to disable > auto-fill-mode. > There are probably other options. Much thanks for your help. I think I'll just add "turn-off-auto-fill" to the mode hook. Sebastian Wiesner ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2013-03-10 15:34 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-03-09 14:06 Derived modes and mode hooks Sebastian Wiesner 2013-03-09 14:31 ` Xue Fuqiao 2013-03-09 14:43 ` Sebastian Wiesner 2013-03-09 15:56 ` Stefan Monnier 2013-03-09 16:25 ` Sebastian Wiesner 2013-03-09 16:43 ` Eli Zaretskii 2013-03-09 17:03 ` Sebastian Wiesner 2013-03-09 17:51 ` Eli Zaretskii 2013-03-09 18:58 ` Sebastian Wiesner 2013-03-09 19:31 ` Eli Zaretskii 2013-03-09 19:49 ` Sebastian Wiesner 2013-03-09 20:22 ` chad 2013-03-10 5:53 ` Stefan Monnier 2013-03-10 15:34 ` Sebastian Wiesner
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.