Currently, every variable is shown in the table of contents of the
reference manual. Variable list is over 400 items long. This makes the
ToC difficult to work with.
Removing is done by adding an overwriting template for the parent of
variables section (that is sect1 tag with id="variables"). In
---
init.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/init.h b/init.h
index 06d4cc9a..f0d2c697 100644
--- a/init.h
+++ b/init.h
@@ -920,7 +920,7 @@ struct option_t MuttVars[] = {
{ "dotlock_program", DT_PATH, R_NONE, {.p=}, {.p=BINDIR
"/mutt_dotlock"} },
/*
**
* Change the wording for some options to be imperative.
* Rename parameters to be descriptive ("draft" instead of "file").
* Mention possible values for -m parameter.
* Change "file [...]" to "file ..." as ellipsis already implies it's
optional.
* Format entries in the SYNOPSIS to avoid
> well, I have in mind at least three (Unix, the BSDs and groff).
My system uses mandoc. It's used as the default formatter for man
pages in BSDs these days. Mandoc's linter complains about setting
fonts (expanded from .NS macro):
> It depends on which manpage implementation you're using.
> (I use it when it's available).
I think it's specific to groff.
Do you mean use it for man pages or general roff
\fC is not actually a valid escape sequence. Using it results in
misplaced underlined formatting.
---
I checked resulting muttrc.man. Using bold for terms highlighted with
\fC in man page seems apropriate.
doc/makedoc.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
> A sole "Re:" is equally spammy, I've seen enough spam trying to hit with
> just that.
I don't think we should be focusing on combating spam with these
subjects. Spammers will probably pick up on any pattern we might come
up with.
The reason I mentioned "spamminess" is that "Re: your mail",
> > "Re:" is a standard that should not be translated.
>
> Except some languages don't use it.
I think, many languages include Latin words and abbreviations in some
form. There are a many Latin words used in biology, medicine,
philosophy, formal literature etc.
I would argue that Latin, being a
> > First, "Re: your mail" sounds like a spam mail heading and doesn't
> > convey any useful information.
>
> True enough, but, the fault is with the original sender for not
> providing a meaningful subject, and if they don't want to receive
> responses that look like spam they should...not do
This affects prefilled subject of a reply to an email with an empty
subject.
---
Let me explain why I think this is a good idea.
First, "Re: your mail" sounds like a spam mail heading and doesn't
convey any useful information.
Second, setting the subject to just "Re:" will enable the user to
Mutt supported processing $XDG_CONFIG_HOME/mutt/muttrc for a while
now, but mutt(1) man page hasn't been updated to reflect that.
This will also replace .IP with .TP to use one line per file name and
highlight file names with .I which is common practice in manual
formatting.
---
doc/mutt.man |
> Note the comment in that function about calls to menu->color() needing to be
> made before mutt_window_move() because of IMAP messages that could relocate
> the cursor.
My mistake. I misread the comment and assumed it was talking about
that one specific place and not general order of
> One suggestion might be to remove the mutt_attrset_cursor() calls before
> print_enriched_string(,,1). And inside print_enriched_string() instead:
We can even go a step further an use this ATTRSET (base_color) inside
print_enriched_string() unconditionally. Then top-level ATTRSET in
both
> Maybe search?
Add support for $cursor_overlay in pager searches
diff --git a/pager.c b/pager.c
index 740803eb..28a4deed 100644
--- a/pager.c
+++ b/pager.c
@@ -313,7 +313,7 @@ resolve_color (struct line_t *lineInfo, int n, int cnt, int
flags, int special,
if (color != last_color)
{
-
I'm sorry for the duplicate, it looks like I messed up my config while
testing patches and didn't use list-reply properly last time.
> I've only taken a quick look at the patch - I don't have time to look
> closely or test right now.
>
> It looks like this version is now changing behavior with
> > -static void print_enriched_string (int attr, unsigned char *s, int
> > do_color)
> > +static void print_enriched_string (int base_color, unsigned char *s, int
> > do_color, int is_current)
>
> I don't like the parameter to be named is_current but doesn't reflect that
> fact in the callers.
Hi,
Here are some updates to merging colors logic.
First, there's a bug I've introduced during a rewrite: attributes
should always be merged, not only when indicator background or
foreground is set.
Here is the correct version:
diff --git a/color.c b/color.c
index 8f3c3ba7..cee39905 100644
---
17 matches
Mail list logo
