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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
