| 1 |
On 03/16/2017 04:08, Brian Dolbec wrote: |
| 2 |
> On Thu, 16 Mar 2017 09:43:08 +0200 |
| 3 |
> Alexandru Elisei <alexandru.elisei@×××××.com> wrote: |
| 4 |
> |
| 5 |
>> On Thu, Mar 16, 2017 at 12:32 AM, Brian Dolbec <dolsen@g.o> |
| 6 |
>> wrote: |
| 7 |
>>> That could be pretty hard to do for all messages. |
| 8 |
>>> Especially messages with embedded data |
| 9 |
>>> |
| 10 |
>>> eg: "%s is missing %s required use flag..." % ('sys-apps/foo', |
| 11 |
>>> 'bar') |
| 12 |
>> |
| 13 |
>> For that case we could use: |
| 14 |
>> |
| 15 |
>> "%s is missing %s required use flag..." % \ |
| 16 |
>> % ('sys-apps/foo', 'bar') |
| 17 |
> |
| 18 |
> Yes, but that is not what I meant. When you are searching the code for |
| 19 |
> a message. |
| 20 |
> |
| 21 |
> the message in your terminal would read |
| 22 |
> "sys-apps/foo is missing bar required use flag..." |
| 23 |
> |
| 24 |
> It may not be obvious to people to break up the text to search into 2 |
| 25 |
> strings. "is missing" and "required use flag..." trying one, failing |
| 26 |
> that try the other to find the code location. Then there is the |
| 27 |
> problem of translations moving/re-arranging the text to suit the |
| 28 |
> language (minor I know, but still a factor to consider). |
| 29 |
> |
| 30 |
> |
| 31 |
>>> I know I don't always enforce the line length for a few characters, |
| 32 |
>>> also when clarity is more important than line length. |
| 33 |
>> |
| 34 |
>> I totally agree with that. |
| 35 |
>> |
| 36 |
>>> We could also increase the max. line length to something like 120 |
| 37 |
>>> or 130. |
| 38 |
>> |
| 39 |
>> I think more people should chime in on that. I use vertical splits for |
| 40 |
>> the screen when coding, and 120 characters is too long for me, but if |
| 41 |
>> the preferred width ends up changing to 120 or 130 I can work with it. |
| 42 |
>> |
| 43 |
> |
| 44 |
> You need to get some large 4K monitors... love them :D |
| 45 |
> I treated myself to two 28 inch ones during boxing week sales. |
| 46 |
> My aging eyes love them :) They are so much better than my old 24 inch |
| 47 |
> 1080p monitors. Those were getting tired/starting to loos clarity along |
| 48 |
> with my eyes working at them all week long. I now work with larger |
| 49 |
> fonts which are still physically smaller than my old monitors, but |
| 50 |
> sooooo much clearer. My eyes don't get nearly so tired as they did |
| 51 |
> with my other monitors. |
| 52 |
> |
| 53 |
> </bragging> ;) |
| 54 |
> |
| 55 |
> |
| 56 |
> My work has a 130 col limit. With an editor at that, |
| 57 |
> plus a wide, open files pane on the left of the editor window, I still |
| 58 |
> have another large terminal window open to it's right with some bare |
| 59 |
> screen real-estate patches and borders... ;) Not to mention nearly 100 |
| 60 |
> lines of code view-able in the editor. |
| 61 |
|
| 62 |
Not breaking the error messages across lines is now a checkpatch.pl warning in |
| 63 |
the kernel, for the specific reason of making it easy to grep for error |
| 64 |
messages. You're only required to drop to the next line if, after closing the |
| 65 |
string, there are any printk() variables needed. |
| 66 |
|
| 67 |
So, IMHO, if the kernel does it this way now, I don't see a problem with us |
| 68 |
doing it this way. |
| 69 |
|
| 70 |
-- |
| 71 |
Joshua Kinard |
| 72 |
Gentoo/MIPS |
| 73 |
kumba@g.o |
| 74 |
6144R/F5C6C943 2015-04-27 |
| 75 |
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 |
| 76 |
|
| 77 |
"The past tempts us, the present confuses us, the future frightens us. And our |
| 78 |
lives slip away, moment by moment, lost in that vast, terrible in-between." |
| 79 |
|
| 80 |
--Emperor Turhan, Centauri Republic |
Archives