Re: Introducing separate strings for quick bar items

Egmont Koblinger wrote: On Tue, Jul 12, 2005 at 08:18:20PM +0200, Roland Illig wrote: What about "ButtonBar:Quit" or "ButtonBar|Quit"? This scheme would also be extensible to other special cases, like menu strings, dialog boxes, etc. Nice idea. If it gets widely used in mc, we could even intr

Re: Introducing separate strings for quick bar items

On Tue, Jul 12, 2005 at 08:18:20PM +0200, Roland Illig wrote: > I suggest another naming scheme for it, as the "1" has no intuitive > interpretation for me in this case. You're right, I just wrote it because I remember I saw it somewhere (I don't know where). > What about "ButtonBar:Quit" or >

[bug #6415] syntax highlighting breaks on more complicated shell regexps

Update of bug #6415 (project mc): Status:Wont Fix => Confirmed Open/Closed: Closed => Open Release: 4.5.55 => All versions __

Re: Introducing separate strings for quick bar items

Egmont Koblinger wrote: A more generic approach is to add the same prefix to all these strings (e.g. "1Quit"), make a comment for translators to leave that prefix as it is (e.g. "1Afsltn") and strip that prefix at runtime. I suggest another naming scheme for it, as the "1" has no intuitive int

[bug #13728] superflous copying instead of moving

Follow-up Comment #5, bug #13728 (project mc): A really fast move can happen only under the circumstances described in the quoted text - everything else will be suboptimal. I don't want to block any attempts to move the directory if the existing directory is not empty, but it cannot be performed

[OT] Re: [PATCH] Choose syntax

Hello, Marking it out of topic so it can be distinguished from the real discussion :) On Tue, 12 Jul 2005, Oswald Buddenhagen wrote: > On Tue, Jul 12, 2005 at 02:20:10PM +0300, Pavel Tsekov wrote: > > Though it didn't become clear from his posts which part of the > > construct causes the compile

[bug #13728] superflous copying instead of moving

Follow-up Comment #4, bug #13728 (project mc): > Does `bar/name/' contain any entries or is it empty ? > empty, but this should not matter. i don't think we want this susv3-compliant behavior. at the top level, if the target is an existing directory (empty or not), we want to move _into_ this dir

[bug #13727] recursive "are same file"

Follow-up Comment #2, bug #13727 (project mc): well, one could simply do this same-inode check on directories as well. this would give exactly the desired effect - one error message box (for the top-level directory) and bye bye. ___ Reply

Re: [PATCH] Choose syntax

On Tue, Jul 12, 2005 at 02:20:10PM +0300, Pavel Tsekov wrote: > Though it didn't become clear from his posts which part of the > construct causes the compiler to barf > the declaration of constants. the const keyword as an attribute to pointers is "new" as well, but supported by most compilers for

Re: [PATCH] Choose syntax

Hi Roland, On Mon, 2005-07-11 at 08:33, Roland Illig wrote: > #include "../src/global.h" > (see HEAD/maint/headers.txt) If you can explain me why I need this seemingly redundant #include I might be convinced ;) . Please also put your reasonings down in headers.txt. Some improvements: - g_free()

Re: [PATCH] Choose syntax

Hi Pavel, On Tue, 2005-07-12 at 13:28, Pavel Tsekov wrote: > How about informing the caller how much memory should be allocated ? The > caller passes a pointer to integer, which is filled with the number of slots > it allocated, to the callee. The callee finds out that the slots are not > enough,

[bug #13727] recursive "are same file"

Follow-up Comment #1, bug #13727 (project mc): What do you think should be done in this case ? 1) Silently ignore the fact and continue 2) Pop up a box with several choices 3) Something else ___ Reply to this item at:

[bug #13728] superflous copying instead of moving

Follow-up Comment #3, bug #13728 (project mc): Does `bar/name/' contain any entries or is it empty ? I ask this question because of the following paragraph in the description of rename() in SUSv3: [...] If the old argument points to the pathname of a directory, the new argument shall not point t

Re: Introducing separate strings for quick bar items

Hello, On Tue, 12 Jul 2005, Egmont Koblinger wrote: > By the way: the bottom right corner of mc has "Quit" while the File menu > contains "eXit" associated to F10. Shouldn't they be called the same? Good catch! Just checked Volkov Commander and it has Quit in both places. But what should MC do i

Re: [PATCH] Choose syntax

Hello, On Tue, 12 Jul 2005, Leonard den Ottolander wrote: > > ... as well as any suggestions to use gboolean when a variable is > > clearly meant to be of a boolean type ... > > As I said, ignoring any suggestion to use NULL, TRUE or FALSE (for now). > I'm quite comfortable with using 0, !0 and 0

Re: [PATCH] Choose syntax

Hello, On Tue, 12 Jul 2005, Leonard den Ottolander wrote: > On Tue, 2005-07-12 at 08:41, Roland Illig wrote: > > exec_syntax_dialog should not use the constant MAX_SYNTAX_FILES, but > > some parameter names_size. That makes the relation between them tight > > closer. > > As I've explained the cal

Re: Introducing separate strings for quick bar items

Hi Egmont, On Tue, 2005-07-12 at 13:13, Egmont Koblinger wrote: > Quite ugly approach since it relies on "Quit" actually being shorter than 6 > chars. The quick bar strings all have a maximum length of 6 chars. > And what do you do at RenMov, Delete, PullDn? I think the former and the latter a

Re: [PATCH] Choose syntax

Hello, On Tue, 12 Jul 2005, Leonard den Ottolander wrote: > On Tue, 2005-07-12 at 09:14, Pavel Tsekov wrote: > > I know that it is cleaner and better. The macro is something that is > > handled by the preprocessor i.e. before the compiler steps in. So the > > compiler doesn't know anything about

Re: Introducing separate strings for quick bar items

On Mon, Jul 11, 2005 at 11:02:31PM +0200, Leonard den Ottolander wrote: > F.e. I've translated N_("Quit") to "Afsltn" in Dutch. This is short for > "Afsluiten". Now this string fits nicely in the quick bar, but it's > quite ugly as a header in the quit dialog. By defining the quit string > for the

Re: [PATCH] Choose syntax

Hi Pavel, On Tue, 2005-07-12 at 09:14, Pavel Tsekov wrote: > I know that it is cleaner and better. The macro is something that is > handled by the preprocessor i.e. before the compiler steps in. So the > compiler doesn't know anything about MAX_ENTRY_LEN . If it knew it could > do useful checks (l

Re: [PATCH] Choose syntax

Hi Roland, On Tue, 2005-07-12 at 08:52, Roland Illig wrote: > > +void > > +edit_syntax_dialog () { > > ... as well as any suggestions to declare proper function prototypes ... Again not blatantly. I'll fix this. Leonard. -- mount -t life -o ro /dev/dna /genetic/research

Re: [PATCH] Choose syntax

Hi Roland, On Tue, 2005-07-12 at 08:41, Roland Illig wrote: > exec_syntax_dialog should not use the constant MAX_SYNTAX_FILES, but > some parameter names_size. That makes the relation between them tight > closer. As I've explained the caller cannot make any sensible guess about the size of the

[bug #13751] support for x clipboard wanted

URL: Summary: support for x clipboard wanted Project: GNU Midnight Commander Submitted by: ossi Submitted on: Tue 07/12/2005 at 10:44 Category: Editor

Re: [PATCH] Choose syntax

Hi Roland, On Tue, 2005-07-12 at 08:52, Roland Illig wrote: > - Blatantly ignoring any suggestions to follow common #include practice. You mean because I forgot to #include "../src/global.h". That was unintentional. However, you might want to explain (in headers.txt) why this is necessary. > ...

[patch #1202] Xterm title with format string (MC_XTITLE env var)

Follow-up Comment #1, patch #1202 (project mc): another worthwhile power user patch that gets zero attention ... :( a much simpler variant that is limited to a fixed [EMAIL PROTECTED]:/path has been posted by jindrich novy, but i'm no fan of it. so back to this patch: a --title command line op

[bug #13750] restoring xterm window title on exit wanted

URL: Summary: restoring xterm window title on exit wanted Project: GNU Midnight Commander Submitted by: ossi Submitted on: Tue 07/12/2005 at 09:26 Category: No

Re: [PATCH] Choose syntax

On Tue, Jul 12, 2005 at 11:30:27AM +0300, Pavel Tsekov wrote: > I've tried not so recent Metrowerks, not so recent lcc and BCC 5.5 - > they all compiled the code in question fine. > usually the compilers shipped with proprietary unixes are the biggest pita, like the one from sun. the ones that try

Re: [PATCH] Choose syntax

Hello, On Tue, 12 Jul 2005, Oswald Buddenhagen wrote: > On Tue, Jul 12, 2005 at 10:26:03AM +0300, Pavel Tsekov wrote: > > > > static const int MAX_ENTRY_LEN = 40; > > > > > > > this is c++ (well, except that const implies static, i heard). maybe > > > its in newer c standards, too, but i'm not su

Re: [PATCH] Choose syntax

On Tue, Jul 12, 2005 at 10:26:03AM +0300, Pavel Tsekov wrote: > > > static const int MAX_ENTRY_LEN = 40; > > > > > this is c++ (well, except that const implies static, i heard). maybe > > its in newer c standards, too, but i'm not sure we want to depend on > > them. > > It is a good practice. > su

Re: [PATCH] Choose syntax

Hello, On Tue, 12 Jul 2005, Oswald Buddenhagen wrote: > On Mon, Jul 11, 2005 at 06:02:09PM +0300, Pavel Tsekov wrote: > > Instead of a macro you could use the following construct: > > > > static const int MAX_ENTRY_LEN = 40; > > > this is c++ (well, except that const implies static, i heard). may

Re: [PATCH] Choose syntax

On Mon, Jul 11, 2005 at 06:02:09PM +0300, Pavel Tsekov wrote: > Instead of a macro you could use the following construct: > > static const int MAX_ENTRY_LEN = 40; > this is c++ (well, except that const implies static, i heard). maybe its in newer c standards, too, but i'm not sure we want to depe

Re: [PATCH] Choose syntax

Hello, On Mon, 11 Jul 2005, Leonard den Ottolander wrote: > On Mon, 2005-07-11 at 17:02, Pavel Tsekov wrote: > > Instead of a macro you could use the following construct: > > > > static const int MAX_ENTRY_LEN = 40; > > Yes, I could to that. Why do you feel this is a cleaner approach? I know tha