[Pan-users] Re: changing your underscores; some old problems coming back (Re: updated info)

[Duncan]

SciFi posted on Wed, 04 Aug 2010 18:59:52 +0000 as excerpted:

> Hi,
> 
> Having the underscores being placed into the generated folder-name(s)
> [based on the posted Subject line(s)] was driving me crazy.  ;) So I put
> this change in on your testing branch updates:

> [ s/_/ / ]

I'd suggest that be an option, perhaps in preferences.xml but not
cluttering the GUI.  Some people prefer spaces as they're
"less annoying" (as you said) visually and to type, while others
prefer underscores, due to space in path names normally needing
escaped or quoted.

Actually, I generally prefer dashes (-) here, avoiding the path
quoting issues while being less difficult to type than underline
(no shift), tho the key is still in an odd location (on US-layout
keyboards, anyway), so slightly difficult to type, but that's the
case with about any non-alpha character but the ".", which has its
own issues, being the traditional extension delimiter.  (Still,
I'm finding myself using the dot separator more frequently of late.)

So I'd suggest picking a default (might as well keep it the
underscore since that's what it is now), but putting an option
in preferences.xml that allows the choice of any character.  I
was going to suggest an option between the three or four, but
for an option in the config file only, letting it be any character
(or character sequence, or even "" for nothing) is easier to
convey via option name, and just as easy to implement.

So something like (default value shown):

<string name='path_separator' value='_'/>

Since it's a simple string value, if a user wanted, they could
set value='_separate_me_', or something equally "crazy".

IOW, no need to confine it to a single character.  BUT, do note
that there'd need to be a fallback to default if the user includes
an illegal character in the string.  (Implementor's option whether
it falls back to replacing just the illegal character, or the
entire string.)

> I am also noticing another problem which had been presumably
> fixed a while back in the gnome repo, I thought.
> I brought up a 'reply' of your message just now and Pan decided to
> re-wordwrap some of it despite "Wrap Text" /not/ being in effect on my
> panel. You can see it below, where GMane's 'footnote' is: GMane has the
> Pan-users- munged address on a separate line but Pan decided to
> reverse-wordwrap it as you see now.
> Things like that are happening in other groups on other servers (GN, AW,
> etc).

My frustration hasn't been so much in the displayed rewrap, but
in the posting rewrap.

IIRC, pan used to rewrap the edit window "statically".  That is,
I could set it wrapped and type in the normal text of my reply,
then hit unwrap, to allow me to fix the wrapping of specific
lines (error output, code, etc) as necessary.  Now, when I hit
unwrap, pan unwraps the normal text as well, so then I have
to go back and wrap it manually!

I hate that, but as I've seen the struggles around getting
wrapping behavior "right" over the years, I've not mentioned it
until now, as it seems there'll always be some element of the
auto-wrapping behavior that's not entirely "right".

What'd /really/ be nice would be a "wrap selected" function
and toolbar button.  That way, a post could be unwrapped by
default for verbatim code, error messages and the like, but
allow select-and-wrap on demand for normal text.

That would considerably lessen the impact of issues like the one
below, as well.

Since we're on the subject....   The behavior with /
italics/ and filesystem path markup when wrapping has irritated
me for awhile.  If the "/" appears near the wrap point,
it'll be placed, often entirely by itself, at the end of the
previous line, leaving the rest of the word/path on the next line
improperly marked up, like the above (tho that one was generated
manually for illustration purposes, as I have no-wrap set ATM).

Path example: /
usr/share/doc/cups-1.4.4/README.txt

The "/" case the the one that hits me most often, but I've seen
it happen with others (like "-") as well.

If that could be fixed, it'd certainly eliminate a source of
frustration here, but as I said, I've seen Charles struggle
with wrapping over the years (and that's his code, not khaley
repo changes, and select-N-wrap would alleviate this issue to
some extent as well, as mentioned above), and understand the
difficulty in getting the behavior "consistently correct",
so if I must continue to live with it, I will.

> Quite some time ago, I thought you/someone had fixed the right-most
> column in the header listing pane so that its column-width settings
> are 'remembered' such that the column is fully in view and to keep the
> lower horizontal scroll-bar from opening up.

Hmm...  Indeed.  Here, given a wide display (1920 px), I've
dealt with the issue by setting the header pane full-width
(I have the header pane full-width at the top, groups pane
to the /right/ on the bottom, body pane is still well more
than wide enough, @ probably 120 characters or so, for
80-char-line display), AND setting the least important
column (bytes here as well) to the right.  My connection
is fast enough and I rarely enough do binaries these days
(and the next-left column is lines), that it doesn't
generally matter if I see the full bytes column or not,
so it doesn't generally bother me.  But it /would/ be nice
to eliminate the vertical space taken by the horizontal
scroller, thus allowing the display of one more header
line.

You're right.  It does seem to be that the width calculation
doesn't account for the vertical scroller.  It's a tiny bit
on a full 1920 screen width pane, but a frustrating tiny bit
it is, especially given the fact that the bytes column is
/way/ wider than any of its contents.

> I can file bugreports, still, at gnome.org, if we need to.
> Are we going to continue doing that
> whatever the outcome of the possible
> coming "maintainership change"?

Good question.

Actually, if my empathy with khaley's in any sort of tune ATM,
that's likely one of the reason's "they're" (recalling the
recent subthread) hesitant to take full maintainership.
Currently, it's a hobby "they" enjoy, being able to pick and
choose bugs, fixing them at leisure, and receiving the
gratefulness of the community for doing so, even when the
bug chosen might not have been the worst or affected the
most people.

When one accepts actual maintainership of a project, even tho
it's still volunteer, there's a lot more responsibility involved,
and while one certainly /can/ still pick and chose bugs (who's
going to stop you?), most maintainers will feel a responsibility
to the community and therefore a bit of guilt for ignoring that
bug they just don't feel like working on, even if it's affecting
a slew of users.

There can also be a sense of obligation/demanding from the
community as well, fortunately or unfortunately.  That can be
hard to deal with.  But one only has to take a look at what
happened with pre-4.4 kde4 to see what happens if developers
don't take their responsibility to the community after all
depending on their work, seriously.

It's a serious responsibility to take on, and while I'd
wish it otherwise, I can't fault khaley in the slightest
for not being particularly interested.  Altho at a way
lower level, there are certainly areas where I have similar
hesitancies, projects (like, umm... pan-attach) where I've
not behaved as a "proper" maintainer, and other personal
projects I use myself but have never made public, tho I'm
sure others could use them, in large part because I do NOT
want to take on that responsibility.

> Thanks for any help.
> Pan was already pretty good,
> now it is even more better.
> ;)

=:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman