|
|
DescriptionIssue 2859: Provide \hide and \omit functions for transparent and void glyphs
Both functions take either a grob name to override, or a music
expression to tweak (that is, the type of the argument decides whether
this results in an override or a tweak).
\hide sets #'transparent for the affected grob to ##t,
\omit sets #'stencil for the affected grob to ##f.
Example uses are
\new Voice \with { \omit StringNumber } { c'\4 }
{ <c' \hide g'~> g' }
Also:
Add string-or-music? predicate
Patch Set 1 #Patch Set 2 : Change \omit to \no #Patch Set 3 : Sort \no before \noPageBreak #
Total comments: 1
Patch Set 4 : Change \no back to \omit again. #
MessagesTotal messages: 28
sorry to join the discussion so late... what about using \no for turning stencil off? e.g. \new Voice \with { \no StringNumber } As for the code, it LGTM.
Sign in to reply to this message.
On 2012/09/28 05:18:42, janek wrote: > sorry to join the discussion so late... > > what about using \no for turning stencil off? e.g. > \new Voice \with { \no StringNumber } > > As for the code, it LGTM. It is grammatically cuter in connection with \with, but that's actually more a problem of \with than of \omit: every other command working on properties is a verb: \set, \override, \revert, \hide*. So while \no definitely has its charme, I think it makes sense to stay consistent here. If you want to have more than a one-on-one discussion on it, it might make sense bringing your proposal up on the developer list to give it more exposure. It is not that I am wildly opposed, it is just that I think "\omit" fits better into our naming schemes and is less likely than "\no" to make users think of something different.
Sign in to reply to this message.
On Fri, Sep 28, 2012 at 7:33 AM, <dak@gnu.org> wrote: >> what about using \no for turning stencil off? e.g. >> \new Voice \with { \no StringNumber } > > It is grammatically cuter in connection with \with, but that's actually > more a problem of \with than of \omit: every other command working on > properties is a verb: \set, \override, \revert, \hide*. antother disadvantage of \no is that one would expect plural after it, i.e. \no StringNumbers. So i drop the idea. best, Janek
Sign in to reply to this message.
On 2012/09/28 06:26:03, janek wrote: > On Fri, Sep 28, 2012 at 7:33 AM, <mailto:dak@gnu.org> wrote: > >> what about using \no for turning stencil off? e.g. > >> \new Voice \with { \no StringNumber } > > > > It is grammatically cuter in connection with \with, but that's actually > > more a problem of \with than of \omit: every other command working on > > properties is a verb: \set, \override, \revert, \hide*. > > antother disadvantage of \no is that one would expect plural after it, > i.e. \no StringNumbers. > So i drop the idea. I must be in a controversial mood today since I feel like upholding the idea. I had been thinking about it while fetching breakfast and eating and was about to reenter discussion when I found that I had already convinced you, so this is a bit awkward. The thing is that when a user picks between "\hide" and "\omit" without much of a clue, "\omit" should rather be the preferred choice. \no StringNumber \no TimeSignature \no Clef looks quite no-nonsense. Granted, \omit StringNumber \omit TimeSignature \omit Clef is quite straightforward as well but it looks a bit more like something has been forgotten. I don't thing that the absence of plural is an issue. After all, you can use "no" like "No tie, no shirt: no service!" and you would not say "He was wearing no shirts.". And things like \once\no Clef also work reasonably well. The proposed "\single" is more awkward, but "\single\omit Clef" is not that much better, so maybe "\single" should change. The only drawback is that one might want \yes/\no as a pairing for some different purpose. \no is really a rather important word.
Sign in to reply to this message.
On Fri, Sep 28, 2012 at 9:30 AM, <dak@gnu.org> wrote: > I must be in a controversial mood today since I feel like upholding the > idea. I had been thinking about it while fetching breakfast and eating > and was about to reenter discussion when I found that I had already > convinced you, so this is a bit awkward. lol :) Actually, my cousin gave another reason to change \omit to something else: in his opinion omit implies \once in meaning. Like, \omit StringNumber sounds like only one StringNumber won't be printed. > The only drawback is that one might want \yes/\no as a pairing for some > different purpose. \no is really a rather important word. Yes, this is my concern, too. What about \delete ? Afaik it's not taken yet. On Fri, Sep 28, 2012 at 9:53 AM, Marc Hohl <marc@hohlart.de> wrote: > Am 28.09.2012 09:30, schrieb dak@gnu.org: >> And things like \once\no Clef also work reasonably well. The proposed >> "\single" is more awkward, but "\single\omit Clef" is not that much >> better, so maybe "\single" should change. > > I don't feel quite happy with \single either; just a spontaneous idea: > > does \here work? > > \here\EasyNoteHeadsOn c8 d e > > I'm not sure ... hmm... not quite perfect. No other idea, though... best, Janek
Sign in to reply to this message.
On 2012/09/28 15:06:38, janek wrote: > On Fri, Sep 28, 2012 at 9:30 AM, <mailto:dak@gnu.org> wrote: > > I must be in a controversial mood today since I feel like upholding the > > idea. I had been thinking about it while fetching breakfast and eating > > and was about to reenter discussion when I found that I had already > > convinced you, so this is a bit awkward. > > lol :) > Actually, my cousin gave another reason to change \omit to something > else: in his opinion omit implies \once in meaning. Like, \omit > StringNumber sounds like only one StringNumber won't be printed. Maybe. > > The only drawback is that one might want \yes/\no as a pairing for some > > different purpose. \no is really a rather important word. > > Yes, this is my concern, too. Well, at some point of time we need to crack it open, anyway. > What about \delete ? Afaik it's not taken yet. Guile begs to differ: scheme@(guile-user)> delete $1 = #<procedure delete (_ _)> > On Fri, Sep 28, 2012 at 9:53 AM, Marc Hohl <mailto:marc@hohlart.de> wrote: > > Am 28.09.2012 09:30, schrieb dak@gnu.org: > >> And things like \once\no Clef also work reasonably well. The proposed > >> "\single" is more awkward, but "\single\omit Clef" is not that much > >> better, so maybe "\single" should change. > > > > I don't feel quite happy with \single either; just a spontaneous idea: > > > > does \here work? > > > > \here\EasyNoteHeadsOn c8 d e > > > > I'm not sure ... > > hmm... not quite perfect. > No other idea, though... \here misses the relation to the next item (not that \single is much better). \directly was nicer in that regard. \next would possibly also work.
Sign in to reply to this message.
> The only drawback is that one might want \yes/\no as a pairing for some > different purpose. \no is really a rather important word. I don't think that this is a problem, at least I've never seen someone using \no. It's exactly the same amount to type as ##f. Werner
Sign in to reply to this message.
Too bad that \delete is taken... Maybe using \no is the right choice, although i'd prefer to make this decision after GLISS decides that we don't need \no for something else. As for \single vs. \next, i don't have a strong opinion. Janek
Sign in to reply to this message.
https://codereview.appspot.com/6575048/diff/8001/ly/music-functions-init.ly File ly/music-functions-init.ly (right): https://codereview.appspot.com/6575048/diff/8001/ly/music-functions-init.ly#n... ly/music-functions-init.ly:649: no = why not use "omit" instead of "no" ? I think that "omit" is more specific; "no" is a quite general word and I don't think it makes sense here.
Sign in to reply to this message.
On 2012/10/02 00:23:55, Graham Percival wrote: > https://codereview.appspot.com/6575048/diff/8001/ly/music-functions-init.ly > File ly/music-functions-init.ly (right): > > https://codereview.appspot.com/6575048/diff/8001/ly/music-functions-init.ly#n... > ly/music-functions-init.ly:649: no = > why not use "omit" instead of "no" ? I think that "omit" is more specific; "no" > is a quite general word and I don't think it makes sense here. That has been discussed in comment #1 to comment #8 of this Rietveld review. Could you be a bit more specific about why you consider the conclusion of this discussion invalid?
Sign in to reply to this message.
On 2012/10/02 03:38:42, dak wrote: > On 2012/10/02 00:23:55, Graham Percival wrote: > > https://codereview.appspot.com/6575048/diff/8001/ly/music-functions-init.ly > > File ly/music-functions-init.ly (right): > > > > > https://codereview.appspot.com/6575048/diff/8001/ly/music-functions-init.ly#n... > > ly/music-functions-init.ly:649: no = > > why not use "omit" instead of "no" ? I think that "omit" is more specific; > "no" > > is a quite general word and I don't think it makes sense here. > > That has been discussed in comment #1 to comment #8 of this Rietveld review. > Could you be a bit more specific about why you consider the conclusion of this > discussion invalid? "no is quite a general word". There is some more rationale in comment #4 <URL:http://codereview.appspot.com/6575048#msg4> and take a look at the output of the following command: git grep "#'stencil \+\(= \+\)\?##f" I don't list the output here, but it is more than 200 lines (granted, translations make up for quite a bit here, but even outside of Documentation we have about 50 lines) suggesting that the operation of overriding/tweaking the stencil to #f is not exactly uncommon. So I'd really like to get a better understanding about what makes you come to a different conclusion than the others involved in the discussion.
Sign in to reply to this message.
Still looks good. \omit is better than \no because 'omit' is a verb like we use in parallel constructions \override, etc. A verb is appropriate because your function does perform an action: the \f is conceptually part of the music but your function omits it from the printed score. No is used in several senses in English. Here it serves as an article (like German "kein") but it also an adverb ("nein"). I do not think Latin languages have a single-word negative article. { c\f \no DynamicText c\f\> d\p } for a moment I read "this might look like Dynamic text but it is not". What the function does, though, is order LilyPond to henceforth omit DynamicTexts from the score.
Sign in to reply to this message.
On 2012/10/02 11:01:52, Keith wrote: > Still looks good. What does still look good? > \omit is better than \no because 'omit' is a verb like we use in parallel > constructions \override, etc. A verb is appropriate because your function does > perform an action: the \f is conceptually part of the music but your function > omits it from the printed score. The "verb" aspect was stressed in comment #2 <URL:http://codereview.appspot.com/6575048/#msg2> and put into perspective in comment #4 <URL:http://codereview.appspot.com/6575048/#msg4>, so I'd like to see the points made in comment #4 countered for swaying the decision. > No is used in several senses in English. Here it serves as an article (like > German "kein") but it also an adverb ("nein"). This has been addressed in comment #7 <URL:http://codereview.appspot.com/6575048/#msg7>. > I do not think Latin languages > have a single-word negative article. "nullus". > { c\f \no DynamicText c\f\> d\p } > > for a moment I read "this might look like Dynamic text but it is not". What the > function does, though, is order LilyPond to henceforth omit DynamicTexts from > the score. Or henceforth put no DynamicText in the score. That's pretty much a tossup in meaning. It would be kind of unusual to use this in the middle of music without \once either way. So you'd see either \once\no DynamicText c\f or c-\no\f or c-\single\no DynamicText \f or { \no DynamicText ... or \with { \no DynamicText ... as compared to \once\omit DynamicText c\f or c-\omit\f or c-\single\omit DynamicText \f or { \omit DynamicText ... or \with { \omit DynamicText ... and, as I said, \no/\omit is much more likely to be what a user wants over \hide, so using a more mnemonic abbreviation seems appropriate. This is not really anything that has not been said in previous comments, but I also have seen little indication that the previous comments are being considered and countered, at least with regard to comment #9. I definitely agree that "\omit" is more consistent in its naming scheme to "\no", and I considered breaking this consistency appropriate in order to give \no an edge over \hide and similar and make it more idiomatic. If people don't agree with that design goal, we can change this, but at least I'd want to be sure that this objective has been considered before being dropped.
Sign in to reply to this message.
I know \remove has been taken, but is it possible to make a function (?) know what the context of it's action is? Context not in the LP sense. That is if I use '\remove BLAH', the software 'knows' that it isn't the same as the \remove we also use as opposite of what we currently use \consists for, if that makes sense? That way we are at least coalescing terminology, and not using too many different terms for (at least as far as a standard user is concerned) the same 'kind' of operation. I obviously have no insight into how easy this to make the software 'know', but I guess if I don't ask ....
Sign in to reply to this message.
On 2012/10/02 11:50:04, J_lowe wrote: > I know \remove has been taken, but is it possible to make a function (?) know > what the context of it's action is? \remove is a reserved word, so it is treated specially in the syntax. If we hypothesize that it was a function, determining its context would more or less mean letting it look at (current-module) and make it decide its behavior based on that. However, that does not work when writing things like xxx=\remove yyy since the syntax of \remove needs to be known already at the time \xxx is being defined, and we don't know yet which kind of context it will get called in. So for better or worse, context-dependency is something that can only be implemented in quite limited ways.
Sign in to reply to this message.
@James: good question about \remove. @David: the example you gave helped me understand why the thing James asked about was not quite possible, thanks! It looks that the decision whether to use \omit or \no is really difficult. Personally i consider both of them valid, with slight preference for \no. What about making a poll on user list, just about the name? cheers, Janek
Sign in to reply to this message.
On Tue, 02 Oct 2012 04:42:59 -0700, <dak@gnu.org> wrote: > On 2012/10/02 11:01:52, Keith wrote: >> Still looks good. > > What does still look good? The code, with either choice of naming. > <URL:http://codereview.appspot.com/6575048/#msg4>, so I'd like to see > the points made in comment #4 countered for swaying the decision. The points in comment #4 are true, but weak arguments compared to the desire for consistency in using verb-words to name functions that act on the next element. I suppose '\no Stem' "looks quite no-nonsense" and I can look in the manual to learn what it is doing in its no-nonsense fashion. I do not share your sense that '\omit Flag' makes it look like something was forgotten, but it is a valid concern. > "nullus". I forgot about that, and it does act like an article in things like the French 'nulle part' for 'nowhere'. > It would be kind of unusual to use this in the middle of music without > \once either way. Well, I often suppress dynamics in one part when I am using \partcombine. Sometimes the parts separate, but only due to minor differences in rhythm, so combined dynamics are still clear and look cleaner. scoreDynamicsOff = \tag #'score { \override DynamicText #'stencil = #point-stencil \override Hairpin #'stencil = #point-stencil } scoreDynamicsOn = \tag #'score { \revert DynamicText #'stencil \revert Hairpin #'stencil } (Now that more bugs are fixed, yes, #f is better than 'point-stencil.) Browsing mutopiaproject, I found temporary removals of the Tuplet stencils http://www.mutopiaproject.org/ftp/SchumannR/O25/schumann-widmung/schumann-wid... If you name it '\hide', I'll probably make an '\unHide' to revert the stencil. If you name it \no, I'll name the stencil-restoring function '\restore'. You can paint your shed whatever color you like.
Sign in to reply to this message.
On 2012/10/03 04:04:07, Keith wrote: > If you name it '\hide', I'll probably make an '\unHide' to revert the stencil. > If you name it \no, I'll name the stencil-restoring function '\restore'. You can > paint your shed whatever color you like. \hide and \no are for different purposes (so far, \hide has been unflayed by bikeshedding), but indeed reversal has not been taken into account for our discussion so far. Given existing naming choices, \hide/\unHide is an obvious pairing. \omit/unOmit would be logical but awkward, I'd lead towards \omit/\remit. \no has no good reversion, and the pairing \no DynamicText / \yes DynamicText is too awful to contemplate. So shall we conclude this round of bikeshedding with changing back to \omit and adding \unHide and \remit here? Those would be \reverts, not usable as a \tweak. \remit can be used for reverting other stencil overrides, so one could also call it \reStencil or \restencil, but I am not sure that people will make the connection to \omit then, its most likely use case.
Sign in to reply to this message.
On Wed, Oct 3, 2012 at 8:15 AM, <dak@gnu.org> wrote: > Given existing naming choices, \hide/\unHide is an obvious pairing. > \omit/unOmit would be logical but awkward, I'd lead towards > \omit/\remit. Whoah, i didn't know that "remit" is a proper English word! Sounds like "Kermit" to me... :P (frankly, one of the problems i have with "omit" is the fact that it's not a basic English word - it's better to use simple words for the sake of non-native English speakers) > \no has no good reversion, and the pairing \no > DynamicText / \yes DynamicText is too awful to contemplate. \yes would be horrible. But \restore is not that bad... Janek
Sign in to reply to this message.
On Tue, 02 Oct 2012 23:15:23 -0700, <dak@gnu.org> wrote: > \hide and \no are for different purposes Oops, I forgot we were talking about the name 'no' for the function '\omit'. The command to restore the stencil could be \unOmit or \restore. I had to look up \remit in the dictionary, and couldn't find any meaning that fits this situation.
Sign in to reply to this message.
On 2012/10/03 06:27:56, Keith wrote: > On Tue, 02 Oct 2012 23:15:23 -0700, <mailto:dak@gnu.org> wrote: > > > \hide and \no are for different purposes > > Oops, I forgot we were talking about the name 'no' for the function '\omit'. > > The command to restore the stencil could be \unOmit or \restore. \restore is too generic a name for me, without viable connection to \omit. > I had to look up \remit in the dictionary, and couldn't find > any meaning that fits this situation. Hm? 2. To restore. [Obs.] [1913 Webster] The archbishop was . . . remitted to his liberty. --Hayward. [1913 Webster] Granted, "obsolete" in usage, but a reasonably good pairing for omit. I don't like \unOmit, though it matches the rather hideous \unHide (what was the idea in camelCasing that? "unhide" is a nice proper word, and unhideNotes would have been quite fine), since there is no word "unomit" in English language. That would be "\include", and this is already taken. Or "\reinclude", and that's far too unobvious in its relation to \omit. Incidentally, \unHide _can_ work as a tweak (setting transparent to ##f), whereas \remit or whatever would not know _what_ to restore the stencil to and thus is confined to be a revert.
Sign in to reply to this message.
2012/10/2 <k-ohara5a5a@oco.net>: > No is used in several senses in English. Here it serves as an article > (like German "kein") but it also an adverb ("nein"). I do not think > Latin languages have a single-word negative article. Spanish has «sin» ="without" , "with no" «sin alcohol» ="non-alcoholic" «sin un céntimo» ="penniless" «sin compromiso» ="uncompromised" BTW, \without has come to my mind as an idea for the thread. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com
Sign in to reply to this message.
Francisco Vila <paconet.org@gmail.com> writes: > 2012/10/2 <k-ohara5a5a@oco.net>: >> No is used in several senses in English. Here it serves as an article >> (like German "kein") but it also an adverb ("nein"). I do not think >> Latin languages have a single-word negative article. > > Spanish has «sin» ="without" , "with no" > > «sin alcohol» ="non-alcoholic" > «sin un céntimo» ="penniless" > «sin compromiso» ="uncompromised" > > BTW, \without has come to my mind as an idea for the thread. a) it is totally unrelated to \with, so that would be confusing. Just consider \new Voice \with { \without StringNumber } { ... } b) it is incompatible with my reverse überbikeshed proposal since \un\without would be quite garish -- David Kastrup
Sign in to reply to this message.
On Wed, Oct 3, 2012 at 12:45 PM, David Kastrup <dak@gnu.org> wrote: > incompatible with my reverse überbikeshed proposal since > \un\without would be quite garish omg lol! PS i think that sending a request for name suggestions on user might be a good idea. Maybe they'll propose something else that fits.
Sign in to reply to this message.
Janek Warchoł <janek.lilypond@gmail.com> writes: > On Wed, Oct 3, 2012 at 12:45 PM, David Kastrup <dak@gnu.org> wrote: >> incompatible with my reverse überbikeshed proposal since >> \un\without would be quite garish > > omg lol! > > PS i think that sending a request for name suggestions on user might > be a good idea. Maybe they'll propose something else that fits. Call me an optimist, but I think we are good now. -- David Kastrup
Sign in to reply to this message.
>----Original Message---- >From: dak@gnu.org >Date: 03/10/2012 15:04 >To: "Janek Warchoł"<janek.lilypond@gmail.com> >Cc: <k-ohara5a5a@oco.net>, <reply@codereview-hr.appspotmail.com>, <lilypond-devel@gnu.org> >Subj: Re: Provide \hide and \no functions for transparent and void glyphs (issue 6575048) > >Janek Warchoł <janek.lilypond@gmail.com> writes: > >> On Wed, Oct 3, 2012 at 12:45 PM, David Kastrup <dak@gnu.org> wrote: >>> incompatible with my reverse überbikeshed proposal since >>> \un\without would be quite garish >> >> omg lol! >> >> PS i think that sending a request for name suggestions on user might >> be a good idea. Maybe they'll propose something else that fits. > >Call me an optimist, but I think we are good now. > Apologies if this ship has sailed, but has anyone considered \suppress and \unsuppress? DP
Sign in to reply to this message.
On 2012/10/03 19:32:15, pounderd_lineone.net wrote: > > >----Original Message---- > >From: mailto:dak@gnu.org > >Call me an optimist, but I think we are good now. > > Apologies if this ship has sailed, but has anyone considered \suppress > and \unsuppress? The ship has not sailed, but retailoring the sails at the current stage is probably not going to be met with a lot of enthusiasm. Disadvantages I see for \suppress are that it is longer to type. Also, with \omit/\hide I find it easier to guess which of the two is not even going to reserve space. \omit sounds more like something being left out from the start than \suppress does. Between omitting a sneeze and suppressing a sneeze, the latter sounds like a lot more work. With regard to grammatical awkwardness of reversal, \un\suppress and \un\omit are about on par: unsuppress is not really a proper word even though unsuppressed is (but it is not the past participle of the negation of suppress, but rather the negation of the past participle of suppress). So figure me unimpressed. Here are a few other suggestions: 120 Moby Thesaurus words for "annihilate": abate, abolish, abrogate, abscind, amputate, annul, ban, bar, bereave of life, blot out, bob, bring to naught, cancel, carry away, carry off, chloroform, clip, crop, cull, cut, cut away, cut down, cut off, cut out, decimate, demolish, deprive of life, deracinate, destroy, dispatch, dispose of, do away with, do for, do to death, dock, efface, eliminate, end, enucleate, eradicate, erase, except, excise, exclude, execute, expunge, exterminate, extinguish, extirpate, finish, finish off, immolate, invalidate, isolate, kill, knock off, launch into eternity, liquidate, lop, lynch, make away with, martyr, martyrize, massacre, murder, mutilate, negate, negative, nip, nullify, obliterate, pare, peel, pick out, poison, prune, purge, put away, put down, put to death, put to sleep, quash, quell, quench, raze, remove, remove from life, repeal, revoke, root out, root up, rout, ruin, rule out, sacrifice, set apart, set aside, shave, shear, slay, squash, stamp out, starve, strike off, strip, strip off, suppress, sweep away, take life, take off, take out, truncate, unbuild, undo, uproot, vitiate, void, wipe out, wrack, wreck 81 Moby Thesaurus words for "omit": abandon, abbreviate, abridge, ban, bar, bar out, blink at, blockade, blot out, blue-pencil, bowdlerize, cancel, censor, count out, cross out, cut, cut off, cut out, debar, dele, delete, discount, disregard, edit, edit out, embargo, eradicate, erase, except, exclude, expunge, expurgate, fail, forget, freeze out, goldbrick, goof off, ignore, jump, keep out, kill, leave, leave loose ends, leave out, leave undone, let alone, let be, let dangle, let go, let slide, lock out, malinger, miss, neglect, obliterate, ostracize, overlook, overpass, pass over, pass up, preclude, pretermit, procrastinate, prohibit, reject, relegate, repudiate, rescind, rub out, send to Coventry, shirk, shut out, skip, slack, slight, strike, strike off, strike out, taboo, trifle, void 239 Moby Thesaurus words for "suppress": abate, absorb the shock, allay, alleviate, annihilate, arrest, asphyxiate, assuage, attemper, ban, bank the fire, bar, beat down, bend, black out, block, blunt, bottle up, break, break down, break the fall, bring low, bring to terms, browbeat, bulldoze, bully, castrate, cease, censor, chasten, check, choke, choke off, clamp down on, coerce, compel, conceal, conquer, constrain, control, cork, cork up, countercheck, cover up, cow, crack down on, crush, curb, cushion, cut off, dam up, damp, damp down, dampen, daunt, de-emphasize, deaden, debar, delay, deny, despotize, detain, diminish, disallow, discontinue, domineer, domineer over, downplay, drown, dull, dwarf, embargo, end, enjoin, enslave, exclude, exclude from, extenuate, extinguish, fell, flatten, forbid, gag, grind, grind down, halt, henpeck, hide, hinder, hold back, hold down, hold in, hold in check, hold up, hugger-mugger, humble, humiliate, hush, hush up, hush-hush, impede, inhibit, intercept, interdict, interfere, intermeddle, interrupt, intervene, intimidate, jump on, keep, keep back, keep down, keep in, keep in check, keep quiet, keep secret, keep under, keep under control, keep within bounds, kill, lay, lenify, lessen, lighten, lock in, lord it over, maintain, master, meddle, mitigate, moderate, modulate, muffle, mute, muzzle, neutralize, obstruct, obtund, offset, oppose, oppress, outlaw, overawe, overbear, overmaster, override, overwhelm, palliate, play down, pour water on, preclude, preserve, press heavy on, prevent, prohibit, proscribe, prostrate, put, put down, put out, quash, quell, quench, quiet, reduce, reduce the temperature, refuse, reject, repress, resist, restrain, retain, retard, ride down, ride over, ride roughshod over, rule out, save, save up, say no to, scotch, set back, show consideration, show mercy, show pity, shush, shut down on, shut out, silence, sit down on, sit on, slacken, slow down, smash, smother, snub, snuff out, sober, sober down, soften, soften the blow, squash, squelch, stamp out, stanch, stifle, stop, strangle, stultify, subdue, subjugate, sublimate, suffocate, taboo, tame, temper, terminate, terrorize, throttle, tone down, trample down, trample out, trample underfoot, trample upon, tread down, tread underfoot, tread upon, tune down, tyrannize, tyrannize over, underplay, unman, vanquish, walk all over, walk over, weaken, weigh heavy on, withhold I guess we won't exactly use \send-to-Coventry or \ride-roughshod-over or \tyrannize, but there are several possibilities like \squash or \kill that are definitely feasible. I don't see anything that makes me really call out "oh, I want that over \omit".
Sign in to reply to this message.
On Wed, Oct 3, 2012 at 10:05 PM, <dak@gnu.org> wrote: > > Here are a few other suggestions: > 120 Moby Thesaurus words for "annihilate": [...] Let's call it \slay. After that we only need to create a Dragon grob and we'll have a fairy-tale. ;)
Sign in to reply to this message.
|