Re: mcedit: Is there a way to tell mcedit to start in window mode instead of full screen?
Hi, the options for a cascade (-w/--cascade) and tiling (-T/--tile) arrangement are implemented in https://midnight-commander.org/ticket/4184 patch. Also, menu entries (in Window submenu) are added. You can test the patch, if you like, it would help. On Sat, 16 Jan 2021 at 10:10, bcurrey99 wrote: > The cascading windows is a very nice idea because you could see all of the > files that were opened. > > But if that is too difficult, dividing the screen into two rows of tiled > windows (maximum 6 or 8) would be reasonable . > > Thanks much for your better idea. > Bob Currey > > > Sent from my Galaxy > > > Original message > From: Sebastian Gniazdowski via mc > Date: 1/16/21 9:13 AM (GMT-06:00) > To: mc@gnome.org > Subject: Re: mcedit: Is there a way to tell mcedit to start in window mode > instead of full screen? > > (I'm replying to the list this time, just ensuring that it's not missed) > > Can I ask for clarification: > - when an option, -w for example, will be given, > - then mc should start with the file's window in windowed (not fullscreen > mode), > - for multiple files, possibly arranged the windows in e.g.: cascading way, > ? > > I think that this would involve first creating a CK_WindowCascade action > that would arrange the windows (first exiting fullscreen if needed). > > On Fri, 15 Jan 2021 at 14:32, Bob Currey via mc wrote: > >> I looked on the --help screen but didn't see an option to open in window >> mode >> >> $ mcedit --help >> Usage: >> mcedit [OPTION…] [+lineno] file1[:lineno] [file2[:lineno]...] >> >> >> GNU Midnight Commander 4.8.25-154-g33c84e75e >> >> >> Help Options: >> -h, --helpShow help options >> --help-allShow all help options >> --help-terminal Terminal options >> --help-color Color options >> >> Application Options: >> -V, --version Displays the current version >> -f, --datadir Print data directory >> -F, --datadir-infoPrint extended info about used data >> directories >> --configure-options Print configure options >> -P, --printwd= Print last working directory to specified file >> -U, --subshellEnables subshell support (default) >> -u, --nosubshell Disables subshell support >> -l, --ftplog= Log ftp dialog to specified file >> -v, --view= Launches the file viewer on a file >> -e, --edit= ... Edit files >> >> >> Please send any bug reports (including the output of 'mc -V') >> as tickets at www.midnight-commander.org >> >> Midnight Commander is my favorite "mst have" program on my Linux >> machines. >> >> Thanks for all your efforts :) >> >> Bob Currey >> >> >> ___ >> mc mailing list >> https://mail.gnome.org/mailman/listinfo/mc >> > > > -- > Sebastian Gniazdowski > > -- Sebastian Gniazdowski ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: mcedit: Center current line in middle of screen
On Thu, 21 Jan 2021 at 12:51, Yury V. Zaytsev wrote:
> On Thu, 21 Jan 2021, Sebastian Gniazdowski wrote:
>
> > I have made the wish list on the ticket system:
> > http://midnight-commander.org/ticket/4177
> >
> > Are there any interesting entries? Or: is the direction in them
> > compliant with the maintainer vision?
>
> Sorry, I've used up the time that I can make for mc for the coming months,
> but to make it short, I'd rather side with Andrew.
>
> I'm pretty averse to overloading mcedit with small hardly discoverable
> functions (however useful they are), and bolting on a questionable
> scripting engine on top of that.
>
There are two arguments in the paragraph:
1. Small hardly discoverable features:
2. Questionable scripting engine.
Ad. 1.
I think/I'm hoping that it's just a first impression that the wishlist has
made, mostly because of how long it is. I think that the entries in it are
of the following categories:
A. Small bugfixes.
Like the whitespace leaving on the divided line by the typewriter wrapping,
or the pasting onto an input's initial, faded text, or the find definition
goto-line instead of replacing the file with the same file, or the fix of
ParagraphFormat action, etc.
Such changes are fine as they are rather bugfixes than microchanges, and
bugs can be as small as they can get, because they're bugs that should be
just fixed.
B. New features that are narrow, but sensible.
Like the line joining (vim's J command), character swapping (Ctrl-t in
readline), centering of view (vim's zz command), CapitalizeWord (vim's gUiw
command), LowercaseWord/Letter, ReloadFile action (vim's :edit), or the
to-open-paren indenting, etc.
I think that such changes are yes – narrow – however they're have a good
history in other editors, so it's fine to implement them. All of them
require only small coding.
C. Features by the big F – with big coding required by them.
Like the (30) alternate/updated WindowList command merging (but with a
separation) the entries of the open file list and the editor history, or
the clipboard history, (61) showing of current function in the window bar,
or the (10) word-delimited block paren-like matching (i.e.: MatchBracket
action), MultiSearch listbox filtering, etc.
Such changes are IMO little heavy and require acceptance of the maintainer,
however I strongly believe in them (not sure if all such wishes from the
list, however the above – yes) and I hope that I'll win maintainers
blessing on them.
D. Annoyance resolving changes.
Like the (52) WordRight to jump to the end of word, not to the beginning of
next word, or (41) repeating of Complete to move the selection in the list
to next item, or (46) opening of file without adding it to editor history,
or (53) explicit jumps to previous locations in the file, (56) saving and
restoring of the replaced buffer's undo history.
I think that such changes may be most difficult to convey to the
maintainer. On the other hand, SearchOppositeContinue has found its way to
mcview, and it is from this category – a narrow change to resolve an
annoying problem, so maybe there's hope.
E. Fancy changes.
Like (13) completion of file paths in buffer, (39) go-to filename under the
cursor, (40) repeating of all characters and commands from the last save,
(57) peek of the declaration of the function under the cursor, or the
terminal window support, or (18) bookmark listbox, (32) search results
listbox, etc.
Such changes can be perceived as controversial because of the fanciness and
size of the patches. I think that they need to be "pulled off", which makes
them open for a simple rejection.
F. Creative, eccentric changes.
Like the (17) preview of ExternalCommand, (14) tray with a set of Unicode
symbols, (16) git support, (58) a tags aware window list.
Such changes are rather doomed for a fork fate. 17 and 14 – yes, maybe, but
the git support or 58 – no, rather no chances of acceptance of the
maintainer.
G. Long awaited changes.
Like (5) file browse widget for Edit/SaveFile,(15) "other file" .c ↔ .h
support, (11) CK_WindowCascade / CK_WindowTile, (29) scroll left/right.
Such changes are IMO problematic, because they're known for the maintainer
and fossilized. I however still have hopes for all of the above, especially
the last three.
H. Weird changes
Such changes might be the ones that you and Andrew have biggest objections
to, like 45, 36, 31, 4, 24, 47, etc. I've included them in the wishlist
just to stimulate the grey cells and new ideas. They and the ones from F.
may have caused the allergic reaction of Andrew… And also D., contributing
to the microchanges aura.
Ad.2. Questionable scripting.
Slang is a good language. It e.g.: allows inheritance of structures via,
e.g.:
car = struct {x, y, z}; truck = struct {@car, t};
Slirp is a very reliable tool. Did maybe the kitchensink example scare you
off? Because it's the standard syntax used in such tools, it's virtually
identical to Swig, the main scripting integration
Re: mcedit: Center current line in middle of screen
On Thu, 21 Jan 2021, Sebastian Gniazdowski wrote: I have made the wish list on the ticket system: http://midnight-commander.org/ticket/4177 Are there any interesting entries? Or: is the direction in them compliant with the maintainer vision? Sorry, I've used up the time that I can make for mc for the coming months, but to make it short, I'd rather side with Andrew. I'm pretty averse to overloading mcedit with small hardly discoverable functions (however useful they are), and bolting on a questionable scripting engine on top of that. There are enough fundamental problems with mc codebase, and my vision for it would have been to clean up the core, cover it with tests, and expose its API to an external engine, which provides a high level memory managed language. Everything beyond core could be pushed into this layer and left up to users and distributions... This was pretty much what mc^2 was a prototype for, but very unfortunately we didn't have the capacity to integrate it :-( -- Sincerely yours, Yury V. Zaytsev ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: mcedit: Center current line in middle of screen
On number 5, the file dialog widget is needed for :Open file...Save as...Insert file...Copy to file...Adding this should close ticket #2937.I noticed your references to macro languages and Jed. I used to use Brief and loved its macro language. I still have a working copy that can run on linux with all my macros. The macro language gave it tremendous power and flexibility. Bob Currey Sent from my Galaxy Original message From: Sebastian Gniazdowski via mc Date: 1/20/21 5:27 PM (GMT-06:00) To: "Yury V. Zaytsev" Cc: mc@gnome.org Subject: Re: mcedit: Center current line in middle of screen Hi,I have made the wish list on the ticket system: http://midnight-commander.org/ticket/4177Are there any interesting entries? Or: is the direction in them compliant with the maintainer vision? -- Sebastian Gniazdowski ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: mcedit: Center current line in middle of screen
Hi, I have made the wish list on the ticket system: http://midnight-commander.org/ticket/4177 Are there any interesting entries? Or: is the direction in them compliant with the maintainer vision? -- Sebastian Gniazdowski ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: mcedit: Is there a way to tell mcedit to start in window mode instead of full screen?
The cascading windows is a very nice idea because you could see all of the files that were opened.But if that is too difficult, dividing the screen into two rows of tiled windows (maximum 6 or 8) would be reasonable .Thanks much for your better idea. Bob Currey Sent from my Galaxy Original message From: Sebastian Gniazdowski via mc Date: 1/16/21 9:13 AM (GMT-06:00) To: mc@gnome.org Subject: Re: mcedit: Is there a way to tell mcedit to start in window mode instead of full screen? (I'm replying to the list this time, just ensuring that it's not missed)Can I ask for clarification:- when an option, -w for example, will be given,- then mc should start with the file's window in windowed (not fullscreen mode),- for multiple files, possibly arranged the windows in e.g.: cascading way,?I think that this would involve first creating a CK_WindowCascade action that would arrange the windows (first exiting fullscreen if needed).On Fri, 15 Jan 2021 at 14:32, Bob Currey via mc wrote: I looked on the --help screen but didn't see an option to open in window mode$ mcedit --helpUsage: mcedit [OPTION…] [+lineno] file1[:lineno] [file2[:lineno]...]GNU Midnight Commander 4.8.25-154-g33c84e75eHelp Options: -h, --help Show help options --help-all Show all help options --help-terminal Terminal options --help-color Color optionsApplication Options: -V, --version Displays the current version -f, --datadir Print data directory -F, --datadir-info Print extended info about used data directories --configure-options Print configure options -P, --printwd= Print last working directory to specified file -U, --subshell Enables subshell support (default) -u, --nosubshell Disables subshell support -l, --ftplog= Log ftp dialog to specified file -v, --view= Launches the file viewer on a file -e, --edit= ... Edit filesPlease send any bug reports (including the output of 'mc -V')as tickets at www.midnight-commander.orgMidnight Commander is my favorite "mst have" program on my Linux machines. Thanks for all your efforts :)Bob Currey___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc -- Sebastian Gniazdowski ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: mcedit: Is there a way to tell mcedit to start in window mode instead of full screen?
(I'm replying to the list this time, just ensuring that it's not missed) Can I ask for clarification: - when an option, -w for example, will be given, - then mc should start with the file's window in windowed (not fullscreen mode), - for multiple files, possibly arranged the windows in e.g.: cascading way, ? I think that this would involve first creating a CK_WindowCascade action that would arrange the windows (first exiting fullscreen if needed). On Fri, 15 Jan 2021 at 14:32, Bob Currey via mc wrote: > I looked on the --help screen but didn't see an option to open in window > mode > > $ mcedit --help > Usage: > mcedit [OPTION…] [+lineno] file1[:lineno] [file2[:lineno]...] > > > GNU Midnight Commander 4.8.25-154-g33c84e75e > > > Help Options: > -h, --helpShow help options > --help-allShow all help options > --help-terminal Terminal options > --help-color Color options > > Application Options: > -V, --version Displays the current version > -f, --datadir Print data directory > -F, --datadir-infoPrint extended info about used data directories > --configure-options Print configure options > -P, --printwd= Print last working directory to specified file > -U, --subshellEnables subshell support (default) > -u, --nosubshell Disables subshell support > -l, --ftplog= Log ftp dialog to specified file > -v, --view= Launches the file viewer on a file > -e, --edit= ... Edit files > > > Please send any bug reports (including the output of 'mc -V') > as tickets at www.midnight-commander.org > > Midnight Commander is my favorite "mst have" program on my Linux > machines. > > Thanks for all your efforts :) > > Bob Currey > > > ___ > mc mailing list > https://mail.gnome.org/mailman/listinfo/mc > -- Sebastian Gniazdowski ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: mcedit: Center current line in middle of screen
Hi Sebastian, thank you for sharing this! In fact, I also digged into the source and made a quick fix for my needs before I read your last message. I was surprised how well the API is crafted, so changing small things directly in the C source code is probably the way to go for minor features like this. > I'm thinking that such feature has a minor drawback which can be > additionally addressed – it is little offensive, IMO, to human brain > to observe such jumps. Personally, I have no need for moving the display slowly or gradually, I think this adds complexity. I am a fan of minimalism but fully respect any efforts to make software more accessible. So I am curious if you come up with some changes here, would be interesting. There is major difference in my patch however — and this is important for my personal text editing experience: I mostly feel the need to center the current line when I am already at the bottom of the buffer, eg. editing long text or code and the cursor line is both on the bottom of the window and the buffer. Therefore I made a hack to redraw the window when I am in the bottom half of both window and buffer. Btw, I was also long-time vim and emacs user, but got fed up with many things in both editors, especially with the complexity and bloat which came with third-party packages and extensions. That is why I am still looking for a replacement and mcedit is indeed on the very top of my list. Anyhow, I will upload my patch to your ticket, please feel free to delete/reuse/modify it for your proposed changes. Kind regards, Martin ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: mcedit: Center current line in middle of screen
On Fri, 15 Jan 2021 at 10:58, Yury V. Zaytsev wrote: > Sebastian, if you are motivated and have time to do some serious work on mc, maybe we should talk about a vision first? Thanks for the invite! Yes I'm motivated, I find it very entertaining to work on mc. I wish someone had taken the time instead to integrate the Lua fork by > mooffie. Unfortunately he wasn't up to maintaining his work of a genius > (no kidding) and we don't have resources to take it over. I think that he had one initial mistake, if I can say so – he scripted mc and not mcedit. I think that it's an editor that can gain most of a scripting engine, not a filemanager. > In as far as S-Lang scripting is concerned, it's definitively easy to bolt > it on, but I really wouldn't want to live with the resulting mess. Our > code base is already in a shape bad enough... > I have a very pleasant experience with S-Lang. I've ran my first script displaying a listbox from script after ~2 hours of hacking – thanks to Slirp, the S-Lang version of Swig. It works very, surprisingly well! And it has all the advanced features of Swig (take a look at examples/kitchensink/slirprc if you have time). It looks solid. Basically, to simply export a function to S-Lang, all that is required is to run: slirp header.h, with the declaration in that file and to compile and link the resulting header_glue.c (that slirp automatically creates)! What concerns me about S-Lang is that it's not an object oriented language and that it doesn't have a bool type. However, that might be a good thing, as the engine and the vision will be light thanks to this, maybe… It doesn't make sense to me for you invest your valuable time only to get > your patches criticized or rejected or just rotting on the tracker without > any feedback. If we can agree on a direction, then I think it will be good > for all of us, if we can't - at least it will be good for you, because > then you can spare your time arguing with us and directly setup a fork > instead... :-) > Yes, I had such hunches too. So my intentions are: – to make the gem, that mcedit is, more popular, – to make it grow and flourish mainly by the light scripting engine, but also by regular C work (like e.g.: the tags objects in listboxes patch – really, I don't know how I was using the various Vim tags plugins for years, as it's the mcedit's way – a simple listbox (which can be just built in) – that is the right way to do tags :) – then to utilize the scripting also in regular mc and see what ideas will come up. I'm constantly having ideas on mcedit improvements. I'm saving them to a file… It had like 80 entries, but I've just accidentally deleted it hours ago via a miserable rm -f **/*.#* glob (it expands to all files, not just those with hash in them, so look out) :( however I have a backup that has ~50 entries, uf … So maybe I could do a wish list on the wiki out of it? PS. This gives an idea for an improvement – a saving of the backup file to a predefined directory outside the current tree… Could be done as a script plugin, maybe. -- > Sincerely yours, > Yury V. Zaytsev > -- Sebastian Gniazdowski IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zinit Blog: http://zdharma.org ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: mcedit: Center current line in middle of screen
On Fri, 15 Jan 2021, Sebastian Gniazdowski via mc wrote: I'm also working on adding a S-Lang scripting to it :) It already works on my machine. It was really simple, just invoking SLang_init_all() and that was it, as libslang is already linked :) I have a plugin in it that implements adding and subtracting from number under cursor, for example. When I improve the support (e.g.: add some more S-Lang interface functions that would allow e.g.: moving the vie`w) I submit the patch. I wish someone had taken the time instead to integrate the Lua fork by mooffie. Unfortunately he wasn't up to maintaining his work of a genius (no kidding) and we don't have resources to take it over. In as far as S-Lang scripting is concerned, it's definitively easy to bolt it on, but I really wouldn't want to live with the resulting mess. Our code base is already in a shape bad enough... Sebastian, if you are motivated and have time to do some serious work on mc, maybe we should talk about a vision first? It doesn't make sense to me for you invest your valuable time only to get your patches criticized or rejected or just rotting on the tracker without any feedback. If we can agree on a direction, then I think it will be good for all of us, if we can't - at least it will be good for you, because then you can spare your time arguing with us and directly setup a fork instead... :-) -- Sincerely yours, Yury V. Zaytsev ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: mcedit: Center current line in middle of screen
I've finished coding the support, see https://midnight-commander.org/ticket/4175 for a patch. I'm thinking that such feature has a minor drawback which can be additionally addressed – it is little offensive, IMO, to human brain to observe such jumps. I feel this way basing on the relief that I've noticed when I moved from Vim to MCEdit recently. I was doing "zz" command very often there. I would guess that this has something to do with "rapidly changing pictures" topic in neurobiology. To address this, I propose an enhancement: to move display little slowly, gradually, just to not rudely cut the states of before and after the move. I could use the timers but I've noticed that timer.c has been removed recently. Why? ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: mcedit: Center current line in middle of screen
PS. There's one more patch that I hope will be accepted (after I improve it
according to style guide): https://midnight-commander.org/ticket/4160
On Fri, 15 Jan 2021 at 11:05, Sebastian Gniazdowski
wrote:
> On Thu, 14 Jan 2021 at 15:24, wrote:
>
>> Hi there,
>>
>> to me, mcedit is a hidden gem.
>
>
> For me too. It is so good that I've started to improve it recently. See my
> pending patches:
>
> - https://midnight-commander.org/ticket/4165
> - http://midnight-commander.org/ticket/4169
> - http://midnight-commander.org/ticket/4174
> - http://midnight-commander.org/ticket/4171
>
> I'm also working on adding a S-Lang scripting to it :) It already works on
> my machine. It was really simple, just invoking SLang_init_all() and that
> was it, as libslang is already linked :) I have a plugin in it that
> implements adding and subtracting from number under cursor, for example.
> When I improve the support (e.g.: add some more S-Lang interface functions
> that would allow e.g.: moving the view) I submit the patch.
>
> It struck the right balance between ease of use, advanced features and
>> simplicity.
>
>
> Exactly. And IMO with a light scripting engine it could shine even more
> and be able to compete with other main editors.
>
> However, I miss an important
>> function: The ability to center the current line in the middle of the
>> screen. I could not find it anywhere, maybe someone from the community
>> can help?
>>
>
> This is one of the most missed features by me and it was one of the main
> things that drove me to contribute to mc. Seeing that someone shares my
> view, I'll not wait until the scripting engine will be ready and I'll
> implement the centering in C ("CenterView", perhaps, for the name of the
> command?). It'll be there soon :)
>
> --
> Sebastian Gniazdowski
> IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zinit
> Blog: http://zdharma.org
>
--
Sebastian Gniazdowski
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zinit
Blog: http://zdharma.org
___
mc mailing list
https://mail.gnome.org/mailman/listinfo/mc
Re: mcedit: Center current line in middle of screen
On Thu, 14 Jan 2021 at 15:24, wrote:
> Hi there,
>
> to me, mcedit is a hidden gem.
For me too. It is so good that I've started to improve it recently. See my
pending patches:
- https://midnight-commander.org/ticket/4165
- http://midnight-commander.org/ticket/4169
- http://midnight-commander.org/ticket/4174
- http://midnight-commander.org/ticket/4171
I'm also working on adding a S-Lang scripting to it :) It already works on
my machine. It was really simple, just invoking SLang_init_all() and that
was it, as libslang is already linked :) I have a plugin in it that
implements adding and subtracting from number under cursor, for example.
When I improve the support (e.g.: add some more S-Lang interface functions
that would allow e.g.: moving the view) I submit the patch.
It struck the right balance between ease of use, advanced features and
> simplicity.
Exactly. And IMO with a light scripting engine it could shine even more and
be able to compete with other main editors.
However, I miss an important
> function: The ability to center the current line in the middle of the
> screen. I could not find it anywhere, maybe someone from the community
> can help?
>
This is one of the most missed features by me and it was one of the main
things that drove me to contribute to mc. Seeing that someone shares my
view, I'll not wait until the scripting engine will be ready and I'll
implement the centering in C ("CenterView", perhaps, for the name of the
command?). It'll be there soon :)
--
Sebastian Gniazdowski
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zinit
Blog: http://zdharma.org
___
mc mailing list
https://mail.gnome.org/mailman/listinfo/mc
Re: mcedit: undo warning
On Sun, 10 Sep 2017, Dmitry L. wrote: It looks like a bug for me. In mcedit I have next warning when remove block of text (when length is large than 16384): "Block is large, you may not be able to undo this action" But actually I can undo only when remove block of text with length less than 8190. So, when I remove block of text where 8190 <= length <=16384 I don't get any warning and can't undo this action. That's correct, the condition in question is (end_mark - start_mark) > option_max_undo / 2 where int option_max_undo = 32768 It looks like it should be option_max_undo / 4, according to your observation, but I have no idea why and how come... In any case, please report this bug on the Trac, because otherwise this will get lost on the list. -- Sincerely yours, Yury V. Zaytsev ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
Re: mcedit: basic syntax file for rust language
On Tue, 4 Oct 2016, Laurent Wandrebeck wrote: Please find attached a syntax file to add (basic, and probably still a bit buggy) rust support. Could you please submit a patch via Trac, so it doesn't get lost on the mailing list? Many thanks! -- Sincerely yours, Yury V. Zaytsev ___ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit bug?
On Wed, 30 Mar 2011 15:24:33 +0800 Dmitrij wrote: In mcedit function replace(F4) search string :^$ replacement string: check [x] regular expression and press [Enter], show window Confirm replace and press [Enter] results: STOP Yes, this is known bug: http://www.midnight-commander.org/ticket/1868 -- Andrew ___ mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: mcedit exit bug
Hello, Sorry, the mcedit exit bug was also a false alarm. I've configured mc to exit upon a _single_ Escape. But I got used to the double Escapes in the past too much, so I still do it occasionally. The 1st Escape exits mcedit, but the 2nd goes to the terminal. Sorry again G ___ mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit exit bug
Hello, I've just compiled and installed 58ea06d Merge branch '2417_edit_search_charset' I'm using gnome-terminal 2.30.2 (Ubuntu 10.04.1). Standalone mcedit still eats the 1st typed character after exiting. On the other hand, I can't reproduce the segfault in gzipped file while M-? Search for content. So I seem to be sending HOAX. :-) Best regards Gergely ___ mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit syntax highlighting
Hello Holger Herrlich, Am 2010-08-25 23:02:03, hacktest Du folgendes herunter: If you want to use a syntax highlighting not made available yet, you have to add an entry at the file 'Syntax' -- so copy to ~/.mc/cedit and do it. Thats not fully right, because If you create an Syntax in ~/.mc/cedit the global /usr/share/mc/syntax/Syntax is not more read... This is WHY I sayed, you have to copy the whole directory to your home. Or did I hit a forgotten bug under Woody, Sarge, Etch and Lenny? Note that mc (or maybe mcedit) has to be restarted to take effect Not right... Open a C Source Tree in the left panel and select a *.c file and hit F4 you see the file in the Editor highlighted... On the right panel and select the c.syntax and edit something, save and close it. Go back to the left panel and hit F4... Now it hast the changed syntax without leafing mc :-) Note: I am makeing SYNTAX files, VFS and menus since more then 8 years Thanks, Greetings and nice Day/Evening Michelle Konzack -- # Debian GNU/Linux Consultant ## Development of Intranet and Embedded Systems with Debian GNU/Linux itsyst...@tdnet France EURL itsyst...@tdnet UG (limited liability) Owner Michelle KonzackOwner Michelle Konzack Apt. 917 (homeoffice) 50, rue de Soultz Kinzigstraße 17 67100 Strasbourg/France 77694 Kehl/Germany Tel: +33-6-61925193 mobil Tel: +49-177-9351947 mobil Tel: +33-9-52705884 fix http://www.itsystems.tamay-dogan.net/ http://www.flexray4linux.org/ http://www.debian.tamay-dogan.net/ http://www.can4linux.org/ Jabber linux4miche...@jabber.ccc.de ICQ#328449886 Linux-User #280138 with the Linux Counter, http://counter.li.org/ signature.pgp Description: Digital signature ___ mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: mcedit syntax highlighting
On Sat, 21 Aug 2010, Michelle Konzack wrote: To: mc@gnome.org From: Michelle Konzack linux4miche...@tamay-dogan.net Subject: Re: mcedit syntax highlighting Hello Stanisław Findeisen, Am 2010-08-21 14:56:21, hacktest Du folgendes herunter: On 2010-08-21 03:10, Michelle Konzack wrote: He can put the files under ~/.mc/cedit/ :-D Thanks! It works! What a cool files! :-) In the time when I had found out it, there was not a singel indice, that you can do that... I have ried it out and it worked! But there is a problem with it: If you have /usr/share/mc/syntax/Syntax and ~/.mc/cedit/Syntax the later one takes precedence and if you have only C Source Code defined, any other Syntax files from /usr/share/mc/syntax/ will be ignored. What about copying ALL the mc syntax files to the user's ~/.mc/cedit/Syntax directory? Does that work? FOR THE DEVELOPERS: It would be an advantage, if the developers of MC could do a merge of the two directories with precedence on ~/.mc/cedit/Syntax and if a Syntax file is not found, MC looks into /usr/share/mc/syntax/ Thanks, Greetings and nice Day/Evening Michelle Konzack That makes perfect sense to me Michelle. So each user can have their own custom versions of the mc syntax files. As they are in the user's home directory, they would not get overwritten when there is an update to mc. Kind Regards, Keith Roberts - Websites: http://www.php-debuggers.net http://www.karsites.net http://www.raised-from-the-dead.org.uk All email addresses are challenge-response protected with TMDA [http://tmda.net] -___ mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: mcedit syntax highlighting
Hello Keith Roberts, Am 2010-08-21 19:54:36, hacktest Du folgendes herunter: What about copying ALL the mc syntax files to the user's ~/.mc/cedit/Syntax directory? Does that work? This is what I have done. and it works flawless, but if you have a major update of mc which adds new Syntaxfiles, you have to care about it. That makes perfect sense to me Michelle. So each user can have their own custom versions of the mc syntax files. As they are in the user's home directory, they would not get overwritten when there is an update to mc. Exactly. However, I do not recommend copying the files (at the very first startup of MC) to the users ~/.mc/cedit/ since it could lead to problems with updated exspecialy with less experienced users. Thanks, Greetings and nice Day/Evening Michelle Konzack -- # Debian GNU/Linux Consultant ## Development of Intranet and Embedded Systems with Debian GNU/Linux itsyst...@tdnet France EURL itsyst...@tdnet UG (limited liability) Owner Michelle KonzackOwner Michelle Konzack Apt. 917 (homeoffice) 50, rue de Soultz Kinzigstraße 17 67100 Strasbourg/France 77694 Kehl/Germany Tel: +33-6-61925193 mobil Tel: +49-177-9351947 mobil Tel: +33-9-52705884 fix http://www.itsystems.tamay-dogan.net/ http://www.flexray4linux.org/ http://www.debian.tamay-dogan.net/ http://www.can4linux.org/ Jabber linux4miche...@jabber.ccc.de ICQ#328449886 Linux-User #280138 with the Linux Counter, http://counter.li.org/ signature.pgp Description: Digital signature ___ mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: mcedit syntax highlighting
Hello Keith Roberts, Am 2010-08-20 21:16:11, hacktest Du folgendes herunter: Well you don't say which OS platform you are using. On Fedora 12 mcedit's syntax files are under, /usr/share/mc/syntax/ If you edit your syntax files, be sure to make backup copies somewhere. Because when mc is updated, it WILL overwrite all you edits to your mc syntax files. For what? He can put the files under ~/.mc/cedit/ :-D Thanks, Greetings and nice Day/Evening Michelle Konzack -- # Debian GNU/Linux Consultant ## Development of Intranet and Embedded Systems with Debian GNU/Linux itsyst...@tdnet France EURL itsyst...@tdnet UG (limited liability) Owner Michelle KonzackOwner Michelle Konzack Apt. 917 (homeoffice) 50, rue de Soultz Kinzigstraße 17 67100 Strasbourg/France 77694 Kehl/Germany Tel: +33-6-61925193 mobil Tel: +49-177-9351947 mobil Tel: +33-9-52705884 fix http://www.itsystems.tamay-dogan.net/ http://www.flexray4linux.org/ http://www.debian.tamay-dogan.net/ http://www.can4linux.org/ Jabber linux4miche...@jabber.ccc.de ICQ#328449886 Linux-User #280138 with the Linux Counter, http://counter.li.org/ signature.pgp Description: Digital signature ___ mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: mcedit
On Wed, 10 Mar 2010 08:12:08 -0700 Ben wrote: Regular expressions - no. ^M, no. The format string replace... I don't even understand HOW you would use that to find a control character. %015, no. \015, no. \r, no. %13, no. %0D, no. 0x0D, no. [^M], no. Strange. Enter search string: \r Enter replacement string: empty (*) Regular expression Works fine for me. mc-4.7.1 -- Andrew ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: mcedit
I use mcedit constantly, running it on an OS X 10.5.8 terminal to numerous remote redhat 9 linux machines from within mc, and on occasion invoked as mcedit (which I presume, as per the docs, is just mc -e.). On occasion, I run into a file with ^M at the end of a line in MCEDIT. I can delete these one at a time if I position the cursor right on them. I have tried many things to attempt and use the F4 global search and replace, but nothing seems to work in the first field, the search field. I would leave the replace field empty, because I want them gone. Regular expressions - no. ^M, no. The format string replace... I don't even understand HOW you would use that to find a control character. %015, no. \015, no. \r, no. %13, no. %0D, no. 0x0D, no. [^M], no. There's a [^] field at the end of the line, but I can't seem to get to it with tab, and the mouse flat out does nothing in an mcedit pane. I've been to the documentation (hah!) and I've searched using Google. Nothing. I know I can use sed, etc., to do this, but I don't always have execute privileges in the directories I'm working in, because I'm in remotely via SSH in one pane - the filesystem is remote. Could someone take pity on me and tell me how it's supposed to work? Thanks. ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: mcedit
Hello Ben, On Wed, 10 Mar 2010 09:01:36 -0700 Ben 2blkb...@nemontel.net wrote: I use mcedit constantly, running it on an OS X 10.5.8 terminal to numerous remote redhat 9 linux machines from within mc, and on occasion invoked as mcedit (which I presume, as per the docs, is just mc -e.). On occasion, I run into a file with ^M at the end of a line in MCEDIT. I can delete these one at a time if I position the cursor right on them. I have tried many things to attempt and use the F4 global search and replace, but nothing seems to work in the first field, the search field. I would leave the replace field empty, because I want them gone. Regular expressions - no. ^M, no. The format string replace... I don't even understand HOW you would use that to find a control character. %015, no. \015, no. \r, no. %13, no. %0D, no. 0x0D, no. [^M], no. There's a [^] field at the end of the line, but I can't seem to get to it with tab, and the mouse flat out does nothing in an mcedit pane. I've been to the documentation (hah!) and I've searched using Google. Nothing. I know I can use sed, etc., to do this, but I don't always have execute privileges in the directories I'm working in, because I'm in remotely via SSH in one pane - the filesystem is remote. Could someone take pity on me and tell me how it's supposed to work? You can use \n and make sure you check the regular expression widget. At least it works w/ 4.7.1, even if mcedit completely freezes when you choose All in the confirm replace dialog. Regards, -- wwp signature.asc Description: PGP signature ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: mcedit
On Wed, 2010-03-10 at 10:34 -0700, Ben wrote: Is there truly no way to search for ^M or other embedded control characters? ^M are not the embedded control characters. It's just the way mcedit represents \r's (carriage return character). So if you run dos2unix on the file or search and replace \r's (ASCII 13) with it should do the trick. I guess there've been numerous requests to add an option to not show \r's in the editor, however I don't remember whether they made their way to the Trac or not. Your best bet would be to search the Trac and 1) If such a ticket exists, vote for it 2) If it does not, then create it. -- Sincerely yours, Yury V. Zaytsev ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: mcedit
On Wed, 10 Mar 2010, Yury V. Zaytsev wrote: On Wed, 2010-03-10 at 10:34 -0700, Ben wrote: Is there truly no way to search for ^M or other embedded control characters? ^M are not the embedded control characters. It's just the way mcedit represents \r's (carriage return character). So if you run dos2unix on the file or search and replace \r's (ASCII 13) with it should do the trick. I guess there've been numerous requests to add an option to not show \r's in the editor, however I don't remember whether they made their way to the Trac or not. Your best bet would be to search the Trac and 1) If such a ticket exists, vote for it 2) If it does not, then create it. OK, here is a vote. If those things are in the file, I prefer to see them, thanks. There are occasions when those DOS control characters can really get in the way, and to have a situation where the problem is hidden so that nobody can see exactly what the problem is makes the problem even worse. For example, sometimes one gets some C code from some other place, and somewhere along the way those ^M characters have been stuck on every line, when it is not good at all to have them lurking there. In such situations, the extra control characters are then removable by running the file through dos2unix, for example, and one had better do that. At the same time, I can see that someone else has a different problem and needs not to see them. I can understand his problem, and I sympathize. But please do not try to solve his problem by screwing things up for others. Try to think of another way around his problem, instead. Theodore Kilgore ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: mcedit
On Wed, 2010-03-10 at 16:21 -0600, Theodore Kilgore wrote: At the same time, I can see that someone else has a different problem and needs not to see them. I can understand his problem, and I sympathize. But please do not try to solve his problem by screwing things up for others. Try to think of another way around his problem, instead. I didn't suggest to screw things up for anyone. There've been some discussions on adding an option which would be disabled by default to not to show them, but I don't remember whether they made it to the Trac or not... -- Sincerely yours, Yury V. Zaytsev ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: mcedit
On Wed, 10 Mar 2010, Yury V. Zaytsev wrote: On Wed, 2010-03-10 at 16:21 -0600, Theodore Kilgore wrote: At the same time, I can see that someone else has a different problem and needs not to see them. I can understand his problem, and I sympathize. But please do not try to solve his problem by screwing things up for others. Try to think of another way around his problem, instead. I didn't suggest to screw things up for anyone. There've been some discussions on adding an option which would be disabled by default to not to show them, but I don't remember whether they made it to the Trac or not... Ah. Yes, if an option were available which can work that way, it would take care of the problem. Theodore Kilgore ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: [Midnight Commander] #148: Re: mcedit - fancy tab handling
#148: Re: mcedit - fancy tab handling ---+ Reporter: Patrick Winnertz win...@debian.org | Owner: winnie Type: defect| Status: accepted Priority: major | Milestone: 4.7 Component: mc-core | Version: 4.6.1 Resolution:|Keywords: review vote-metux Blocking:| Blockedby: ---+ Changes (by metux): * keywords: review = review vote-metux Old description: Am Montag 05 Januar 2009 21:40:43 schrieb Janek Kozicki: I'm attaching here the patch which is in use inside debian for a long time to add a shortcut in order to turn this behaviour off and on. Please comment on this patch. Should this also applied against mc-4.6 (which should only hold bugfixes) or should this go only into a coming 4.7 release? Greetings Winnie New description: Am Montag 05 Januar 2009 21:40:43 schrieb Janek Kozicki: I'm attaching here the patch which is in use inside debian for a long time to add a shortcut in order to turn this behaviour off and on. Please comment on this patch. Should this also applied against mc-4.6 (which should only hold bugfixes) or should this go only into a coming 4.7 release? -- branch:148_fancy_tab_handling changeset:c3a1d292fd90ee05dbe3227f5b8428961431e434 -- -- Ticket URL: www.midnight-commander.org/ticket/148#comment:4 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #148: Re: mcedit - fancy tab handling
#148: Re: mcedit - fancy tab handling ---+ Reporter: Patrick Winnertz win...@debian.org | Owner: winnie Type: defect| Status: accepted Priority: major | Milestone: 4.7 Component: mc-core | Version: 4.6.1 Resolution:|Keywords: vote-metux vote-slavazanko approved Blocking:| Blockedby: ---+ Changes (by slavazanko): * keywords: review vote-metux = vote-metux vote-slavazanko approved -- Ticket URL: www.midnight-commander.org/ticket/148#comment:5 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #148: Re: mcedit - fancy tab handling
#148: Re: mcedit - fancy tab handling ---+ Reporter: Patrick Winnertz win...@debian.org | Owner: winnie Type: defect| Status: testing Priority: major | Milestone: 4.7 Component: mc-core | Version: 4.6.1 Resolution: fixed |Keywords: vote-metux vote-slavazanko approved committed-master Blocking:| Blockedby: ---+ Changes (by winnie): * keywords: vote-metux vote-slavazanko approved = vote-metux vote- slavazanko approved committed-master * status: accepted = testing * resolution: = fixed -- Ticket URL: www.midnight-commander.org/ticket/148#comment:6 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #148: Re: mcedit - fancy tab handling
#148: Re: mcedit - fancy tab handling ---+ Reporter: Patrick Winnertz win...@debian.org | Owner: winnie Type: defect| Status: closed Priority: major | Milestone: 4.7 Component: mc-core | Version: 4.6.1 Resolution: fixed |Keywords: vote-metux vote-slavazanko approved committed-master Blocking:| Blockedby: ---+ Changes (by winnie): * status: testing = closed -- Ticket URL: www.midnight-commander.org/ticket/148#comment:7 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #148: Re: mcedit - fancy tab handling
#148: Re: mcedit - fancy tab handling ---+ Reporter: Patrick Winnertz win...@debian.org | Owner: winnie Type: defect| Status: accepted Priority: major | Milestone: 4.7 Component: mc-core | Version: 4.6.1 Resolution:|Keywords: review Blocking:| Blockedby: ---+ Changes (by winnie): * owner: = winnie * status: new = accepted Comment: Setting me as owner in order to get this as fast as possible to master. -- Ticket URL: www.midnight-commander.org/ticket/148#comment:3 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[Midnight Commander] #148: Re: mcedit - fancy tab handling
#148: Re: mcedit - fancy tab handling --+- Reporter: Patrick Winnertz win...@debian.org | Owner: Type: defect| Status: new Priority: major | Milestone: 4.7 Component: mc-core | Version: 4.6.1 Keywords:|Blocking: Blockedby:| --+- Am Montag 05 Januar 2009 21:40:43 schrieb Janek Kozicki: I'm attaching here the patch which is in use inside debian for a long time to add a shortcut in order to turn this behaviour off and on. Please comment on this patch. Should this also applied against mc-4.6 (which should only hold bugfixes) or should this go only into a coming 4.7 release? Greetings Winnie -- Ticket URL: www.midnight-commander.org/ticket/148 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [Midnight Commander] #148: Re: mcedit - fancy tab handling
#148: Re: mcedit - fancy tab handling ---+ Reporter: Patrick Winnertz win...@debian.org | Owner: Type: defect| Status: new Priority: major | Milestone: 4.7 Component: mc-core | Version: 4.6.1 Resolution:|Keywords: review Blocking:| Blockedby: ---+ Changes (by metux): * keywords: = review Old description: Am Montag 05 Januar 2009 21:40:43 schrieb Janek Kozicki: I'm attaching here the patch which is in use inside debian for a long time to add a shortcut in order to turn this behaviour off and on. Please comment on this patch. Should this also applied against mc-4.6 (which should only hold bugfixes) or should this go only into a coming 4.7 release? Greetings Winnie New description: Am Montag 05 Januar 2009 21:40:43 schrieb Janek Kozicki: I'm attaching here the patch which is in use inside debian for a long time to add a shortcut in order to turn this behaviour off and on. Please comment on this patch. Should this also applied against mc-4.6 (which should only hold bugfixes) or should this go only into a coming 4.7 release? Greetings Winnie -- -- Ticket URL: www.midnight-commander.org/ticket/148#comment:2 Midnight Commander www.midnight-commander.org Midnight Development Center ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit - fancy tab handling
Enrico Weigelt said: (by the date of Mon, 5 Jan 2009 19:22:25 +0100) Hi folks, I've just seen that current mcedit (from git tree) has some fancy tab handling (shows -- symbols). When had this been introduced ? I noticed this after upgrading debian etch to lenny. I like it, but sometimes it's inconvenient when I want to copy/paste with mouse. (using shift-mouseclicks) The best if there's a way to turn it on/off. And if it's somewhere easily accessible with menu/shortcuts. -- Janek Kozicki | ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit - fancy tab handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Janek Kozicki wrote: Enrico Weigelt said: (by the date of Mon, 5 Jan 2009 19:22:25 +0100) Hi folks, I've just seen that current mcedit (from git tree) has some fancy tab handling (shows -- symbols). When had this been introduced ? I noticed this after upgrading debian etch to lenny. I like it, but sometimes it's inconvenient when I want to copy/paste with mouse. (using shift-mouseclicks) The best if there's a way to turn it on/off. And if it's somewhere easily accessible with menu/shortcuts. mc-ru-fork have this feature. And toggle space/tabs view via CTRL+v hotkey in editor... I will make valid patch from mc-ru-fork for 'master' at near time. WBR, Slavaz. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAklicpsACgkQb3oGR6aVLprpGACfXjpxS3FTwJ9Fl1e293TPllZo G2kAnjSwU7KODO1ZF+o6bU8nCu6OmtpQ =WpmA -END PGP SIGNATURE- ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit annoying syntax highlight changes
On Sat, Jun 28, 2008 at 02:33:59PM +0200, Jan Engelhardt wrote: starting with mc 4.6.2, there have been changes to the syntax highlighting, specifically displaying whitespace. http://savannah.gnu.org/bugs/?func=detailitemitem_id=13146 -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Confusion, chaos, panic - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit and mail
Hallo, Pablo, Du (pablo) meintest am 10.06.07: Is mail menu usable? How? A config to do before? you need the programme /usr/bin/mail - just install mailx or mailutils. Sorry - doesn't work. The program /usr/bin/mail exists and works fine, but mail under mcedit doesn't work. further you'll want your mail to be delivered, thus you might need to install an MTA (esmtp, exim, postfix, sendmail etc.)... sendmail works - I see much root mail (and other mail). Viele Gruesse! Helmut ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: mcedit and mail
hi again! this list doesn't seem to be quite noisy... :) On Sun, Jun 10, 2007 at 10:31:00AM +0200, Helmut Hullen wrote: [...] Sorry - doesn't work. no need to be sorry for... :-D sendmail works - I see much root mail (and other mail). this is a bit OT, but: a) are you trying to send mail to a local user? b) if not, is a smarthost set? c) are there any error-msgs? 1) open a terminal to have a look at the log of your MTA. e.g. for exim4 i'll type: tail -f /var/log/exim4/mainlog 2) try the following: (you can send a testmail to [EMAIL PROTECTED] if you want; or send it to your proper webmail-account or whatever. at least [EMAIL PROTECTED] should be replaced by your proper user, of course.) [EMAIL PROTECTED]:~$ mail -s testing mail-command [EMAIL PROTECTED] i'm testing the mail-command of mailx. does the local delivery work? Cc: CTRL-D [EMAIL PROTECTED]:~$ mail Mail version 8.1.2 01/15/2001. Type ? for help. /var/mail/redtux: 5 messages 5 new N 1 [EMAIL PROTECTED] Sun Jun 10 15:02 16/519 test N 2 [EMAIL PROTECTED] Sun Jun 10 15:04 15/489 test 2 N 3 [EMAIL PROTECTED] Sun Jun 10 15:04 16/499 test 2 N 4 [EMAIL PROTECTED] Sun Jun 10 15:11 15/564 testing 4 Message 4: From [EMAIL PROTECTED] Sun Jun 10 15:11:08 2007 Envelope-to: [EMAIL PROTECTED] Delivery-date: Sun, 10 Jun 2007 15:11:08 +0200 To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: testing From: Pablo Hoertner [EMAIL PROTECTED] Date: Sun, 10 Jun 2007 15:11:08 +0200 i'm testing the mail-command of mailx. does the local delivery work? x [EMAIL PROTECTED]:~$ mail -s testing mail-command [EMAIL PROTECTED] is my smarthost set? is my mail delivered to [EMAIL PROTECTED] through my mta? Cc: CTRL-D [EMAIL PROTECTED]:~$ cheerio /pablo -- Pablo Hoertner http://redtux.org/ signature.asc Description: Digital signature ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: mcedit and mail
hi! On Sat, Jun 09, 2007 at 09:53:24PM +0200, [EMAIL PROTECTED] wrote: [...] Is mail menu usable? How? A config to do before? you need the programme /usr/bin/mail - just install mailx or mailutils. further you'll want your mail to be delivered, thus you might need to install an MTA (esmtp, exim, postfix, sendmail etc.)... HTH! cheerio /pablo ps: sorry for the delay, but i've previously sent this reply from a wrong address... :( -- Pablo Hoertner http://redtux.org/ signature.asc Description: Digital signature ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: mcedit and mail
hi! On Sat, Jun 09, 2007 at 09:53:24PM +0200, [EMAIL PROTECTED] wrote: [...] Is mail menu usable? How? A config to do before? you need the programme /usr/bin/mail - just install mailx or mailutils. HTH! cheerio /pablo -- Pablo Hoertner http://redtux.org/ signature.asc Description: Digital signature ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: mcedit: usage of Ctrl-Home, Shift-arrows, Ctrl-Insert and similar keys
I think MC should use a configuration file where you can (re)define keys for anything - not just the Learn Keys window, and some way to configure special keys which only work on the console, so that you can use any key combination in the console, and attempt them or redefine them to something else for terminals. On 12/9/06, Dmitri Geller [EMAIL PROTECTED] wrote: Hello everybody, It is a great feature of mcedit to support Ctrl-Home, Shift-arrows, Ctrl-Insert+Shift-Insert on the Linux console. But I would like to have these keys in mcedit running in a text terminal session. I'm using Putty (v 0.58), OpenSuse Linux 10.1, here is output of mc -V GNU Midnight Commander 4.6.1 Virtual File System: tarfs, extfs, cpiofs, ftpfs, fish, undelfs With builtin Editor Using system-installed S-Lang library with terminfo database With subshell support as default With support for background operations With mouse support on xterm and Linux console With support for X11 events With internationalization support With multiple codepages support I've tried different terminal-types in putty: xterm, putty (defined in /etc/termcap) and linux (to use it The Function keys and keypad radiobutton in Putty changed to linux). It means TERM variable was xterm, putty, linux. Nothing helps. Any suggestion how to get these keys working in a terminal? Does it helps to use another terminal program? best regards Dmitri ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc -- Antes de imprimir este correo electrónico, considera tu responsabilidad medioambiental. Please consider your environmental responsibility before printing this email. ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: Antwort: Re: Antwort: Re: mcedit and file locking
On Tue, 26 Sep 2006, [EMAIL PROTECTED] wrote: On Mon, 25 Sep 2006, [EMAIL PROTECTED] wrote: Where is the dead symlink located? In the same directory as the file being edited. If one user opens a file with mcedit for editing and another user does the same with mcedit should he get a message about this fact? Yes. The mc version is 4.5.51 wiht RedHat 7.2 That version doesn't support locking. Locking support was added starting with MC 4.6.0. I've updated MC to 4.6.0 on the RedHat 7.2 system, but there is still no dead symlink and no message editing a file already opened by somebody else. I've tried the same with MC 4.6.1 on a gentoo system, but also no symlink and no message. Is there a special option to activate locking support, or is there something else to do? Well, maybe you are experiencing the problem described here: https://savannah.gnu.org/bugs/?func=detailitemitem_id=13673#options No - it seems not to be the problem - I didn't start the editor from commandline. So I think there must be a kind of bug in the packages I've used (both RedHat and Gentoo). That's pretty strange. I'll look at this if I get some spare time. However is not a priority since the MC source tarball works ok. If this is the case you have to download the patch and apply it to your local source and rebuild. Or you can get the latest snapshot of MC and build it: http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/snapshots/mc-2006-09-25-14.tar.gz Now I have compiled mc-4.6.1 myself and it works fine with locking support. One suggestion for the message sent in case of a locking situation: Default answer is Grab lock - I think to have Ignore lock as default would be the better choice. But this is my personal opinion and I can change the code myself. There is a patch in the MC patches repository at savannah which improves the locking scheme a bit. I think it also does something with the dialog which is presented to the user when a lock is detected... I'll take a look at it again - it was delayed for quite some time now. ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Antwort: Re: mcedit and file locking
On Mon, 25 Sep 2006, [EMAIL PROTECTED] wrote: ist there a way to prevent a file being edited with mcedit by different users at the same time? The MC editor has support for so called advisory locking. This means that a lock is not enforced (say at the OS level) and thus anyone can modify the file at any time. This locking scheme relies on the fact that different processes trying to modify the file will notice that a lock exists and act accordingly. In the case of MC the lock is a dead symlink named in a specific way and whose target contains the owner, the hostname and the pid of the processes which locked the file. This locking scheme is recognized by Jed and Emacs - maybe others too. Where is the dead symlink located? If one user opens a file with mcedit for editing and another user does the same with mcedit should he get a message about this fact? The mc version is 4.5.51 wiht RedHat 7.2 ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: Antwort: Re: Antwort: Re: mcedit and file locking
On Mon, 25 Sep 2006, [EMAIL PROTECTED] wrote: Where is the dead symlink located? In the same directory as the file being edited. If one user opens a file with mcedit for editing and another user does the same with mcedit should he get a message about this fact? Yes. The mc version is 4.5.51 wiht RedHat 7.2 That version doesn't support locking. Locking support was added starting with MC 4.6.0. I've updated MC to 4.6.0 on the RedHat 7.2 system, but there is still no dead symlink and no message editing a file already opened by somebody else. I've tried the same with MC 4.6.1 on a gentoo system, but also no symlink and no message. Is there a special option to activate locking support, or is there something else to do? Well, maybe you are experiencing the problem described here: https://savannah.gnu.org/bugs/?func=detailitemitem_id=13673#options No - it seems not to be the problem - I didn't start the editor from commandline. So I think there must be a kind of bug in the packages I've used (both RedHat and Gentoo). If this is the case you have to download the patch and apply it to your local source and rebuild. Or you can get the latest snapshot of MC and build it: http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/snapshots/mc-2006-09-25-14.tar.gz Now I have compiled mc-4.6.1 myself and it works fine with locking support. One suggestion for the message sent in case of a locking situation: Default answer is Grab lock - I think to have Ignore lock as default would be the better choice. But this is my personal opinion and I can change the code myself. The link name looks like this .#filename, so if you have turned off the listing of hidden you may not see it as well. Thank You for Your help. Karl ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: Antwort: Re: mcedit and file locking
On Mon, 25 Sep 2006, [EMAIL PROTECTED] wrote: On Mon, 25 Sep 2006, [EMAIL PROTECTED] wrote: ist there a way to prevent a file being edited with mcedit by different users at the same time? The MC editor has support for so called advisory locking. This means that a lock is not enforced (say at the OS level) and thus anyone can modify the file at any time. This locking scheme relies on the fact that different processes trying to modify the file will notice that a lock exists and act accordingly. In the case of MC the lock is a dead symlink named in a specific way and whose target contains the owner, the hostname and the pid of the processes which locked the file. This locking scheme is recognized by Jed and Emacs - maybe others too. Where is the dead symlink located? In the same directory as the file being edited. If one user opens a file with mcedit for editing and another user does the same with mcedit should he get a message about this fact? Yes. The mc version is 4.5.51 wiht RedHat 7.2 That version doesn't support locking. Locking support was added starting with MC 4.6.0. ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: Antwort: Re: Antwort: Re: mcedit and file locking
On Mon, 25 Sep 2006, [EMAIL PROTECTED] wrote: Where is the dead symlink located? In the same directory as the file being edited. If one user opens a file with mcedit for editing and another user does the same with mcedit should he get a message about this fact? Yes. The mc version is 4.5.51 wiht RedHat 7.2 That version doesn't support locking. Locking support was added starting with MC 4.6.0. I've updated MC to 4.6.0 on the RedHat 7.2 system, but there is still no dead symlink and no message editing a file already opened by somebody else. I've tried the same with MC 4.6.1 on a gentoo system, but also no symlink and no message. Is there a special option to activate locking support, or is there something else to do? Well, maybe you are experiencing the problem described here: https://savannah.gnu.org/bugs/?func=detailitemitem_id=13673#options If this is the case you have to download the patch and apply it to your local source and rebuild. Or you can get the latest snapshot of MC and build it: http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/snapshots/mc-2006-09-25-14.tar.gz The link name looks like this .#filename, so if you have turned off the listing of hidden you may not see it as well. ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: [PATCH] Re: mcedit stackdumps on exit
Hello Pavel, I might need to get enlightened on how the double free actually takes place. I can't reproduce the warning or crash you describe (FC1, still :) ). I haven't quite grasped the code path. If I understand your explanation correctly the first free takes place in clean_dir() and the second in mc_maybe_editor_or_viewer(). But after the free in clean_dir() fname gets assigned 0 so I don't quite see how the g_free(path) could cause a double free condition. But as I said, I don't fully grasp the code path yet. Anyway, the cleanup you did seems sensible anyway, so let's discuss the patch regardless of my understanding of the alleged double free ;) . On Mon, 2005-06-13 at 15:29, Pavel Tsekov wrote: 1) Exports the global variable `edit_one_file'. What about the other static variables in main.c? Is there any sense in using static global variables at all? 2) The code initializing a dummy `dir_list' entry in setup_dummy_mc() is removed. The argument to setup_dummy_mc() is removed since it is no longer used. 3) mc_maybe_editor_or_viewer() is rearranged to reflect the changes to setup_dummy_mc(). 3) expand_format() is changed so that it will use the `filename' member of WEdit if the MC is started as `mcedit'. `mc_get_current_wd' will be used to determine the current directory `mcedit' mode instead of `panel-cwd'. Finally the code just eats the `u' and `t' format specifiers when in `mcedit' mode. Just a few remarks/questions: - In the second hunk for src/user.c you test for panel, but that test seems redundant as in the previous else for edit_one_file != NULL you assign panel. Shouldn't you skip the test for panel and get the assignment of fname inside brackets? - Is the test in the fifth hunk of src/user.c correct? Not totally grasping that code, but as you test for (!panel) in the 6th hunk (fall through) I was wondering if the test there shouldn't read (panel !panel-marked). Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Re: mcedit stackdumps on exit
On Wed, 2005-06-22 at 13:41, Leonard den Ottolander wrote: - Is the test in the fifth hunk of src/user.c correct? Not totally grasping that code, but as you test for (!panel) in the 6th hunk (fall through) I was wondering if the test there shouldn't read (panel !panel-marked). As an addendum to this, is there any code that tests !panel-something that can be reached in case panel has not been assigned? $ grep -lr \!panel\-\ * src/cmd.c src/file.c src/main.c src/screen.c src/user.c Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Re: mcedit stackdumps on exit
Hello, On Wed, 22 Jun 2005, Leonard den Ottolander wrote: :) ). I haven't quite grasped the code path. If I understand your explanation correctly the first free takes place in clean_dir() and the second in mc_maybe_editor_or_viewer(). But after the free in clean_dir() fname gets assigned 0 so I don't quite see how the g_free(path) could cause a double free condition. But as I said, I don't fully grasp the code path yet. The `fname' pointer in clean_dir() points to a block of memory . The `path' pointer in mc_maybe_editor_or_viewer() points to the same block of memory. `fname' and `path' live at different locations in MC's address space, so zeroing one of them doesn't zero the other one. 3) expand_format() is changed so that it will use the `filename' member of WEdit if the MC is started as `mcedit'. `mc_get_current_wd' will be used to determine the current directory `mcedit' mode instead of `panel-cwd'. Finally the code just eats the `u' and `t' format specifiers when in `mcedit' mode. Just a few remarks/questions: - In the second hunk for src/user.c you test for panel, but that test seems redundant as in the previous else for edit_one_file != NULL you assign panel. Shouldn't you skip the test for panel and get the assignment of fname inside brackets? No. The condition `edit_one_file != NULL' is valid only when you invoke the editor as mcedit (directly from the command line) and not from within the file manager i.e. pressing F4 on a file. I use `edit_one_file' to recognize the difference. If the editor is called from the file manager it is ok to use `panel' because it contains valid data. Good question though - I should have made it clear when I've posted the patch. - Is the test in the fifth hunk of src/user.c correct? Not totally grasping that code, but as you test for (!panel) in the 6th hunk (fall through) I was wondering if the test there shouldn't read (panel !panel-marked). This question should be answered by the explanation above and the clarification below. @@ -235,7 +253,7 @@ expand_format (struct WEdit *edit_widget return (*quote_func) (menu, 0); break; case 's': - if (!panel-marked) + if (!panel || !panel-marked) return (*quote_func) (fname, 0); The meaning of the old code is - if there aren't any selected items in the panel return the name of the file under the cursor. I have extended it to do the same thing if expand_format() is invoked from mcedit (!panel). It is obvious that when you are not using the file manager there is no way to select files so we just return the name of the file being edited. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Re: mcedit stackdumps on exit
Hello, On Wed, 22 Jun 2005, Leonard den Ottolander wrote: On Wed, 2005-06-22 at 13:51, Leonard den Ottolander wrote: As an addendum to this, is there any code that tests !panel-something that can be reached in case panel has not been assigned? $ grep -lr \!panel\-\ * Duh! The ! is of course totally irrelevant. Any test for panel-something for a non existent panel is a cause for a crash... Currently MC always has panels. I have a patch which changes this i.e. panels are instantiated only when they are needed i.e. MC is invoked as file manager. But this is something which should be discussed after the release. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Re: mcedit stackdumps on exit
Hi Pavel, On Wed, 2005-06-22 at 15:24, Pavel Tsekov wrote: Currently MC always has panels. I have a patch which changes this i.e. panels are instantiated only when they are needed i.e. MC is invoked as file manager. But this is something which should be discussed after the release. What I am concerned about is whether tests for panel-something can occur when running mcedit. Have you checked the code paths to make sure this will never happen? Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Re: mcedit stackdumps on exit
Hi Pavel, On Wed, 2005-06-22 at 19:44, Leonard den Ottolander wrote: What I am concerned about is whether tests for panel-something can occur when running mcedit. Have you checked the code paths to make sure this will never happen? Never mind this ;) . I was under the impression panel is a static or global variable, but as it is local my concern about dereferencing NULL pointers is void ;) . That leaves the small code simplification(?) to be addressed. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Re: mcedit stackdumps on exit
Hello Pavel, On Mon, 2005-06-13 at 15:29, Pavel Tsekov wrote: I am posting a patch for review, comments, etc. This is a candidate for mc 4.6.1. I have another patch which is more intrusive and needs much more attention. I'll post later when I am sure it is clean enough - it will be candidate for HEAD. Committed this patch to both PRE and HEAD (with the minor code restructure I mentioned earlier). Thanks for the patch and your patience ;-) . Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit stackdumps on exit
Hi Pavel, On Tue, 2005-06-14 at 22:20, Pavel Tsekov wrote: You are calling for security review but you are denying a patch Now *you* are assuming too much. I haven't denied your patch. I'm just inquiring if adding a single g_strdup() would fix the issue for now. And I wasn't calling for a security review, I just wrongly assumed from your first post there were security implications. At least when I make assumptions I call them that. There's something *you* could learn. - oh, boy. You are t/making this all too personal and I do not appreciate that. I'm asking questions as to establish the nature of this issue and how to best fix it for our stable PRE branch and unstable HEAD. The patch itself is not so big anyway but it is up to you (the developers) to decide whether to review it or not. When I have time. I'm going to enjoy the last parts of spring now it has finally come ;p . Or when one of the others has time. I'm not sure if Roland is willing to review your patch and as I've understood pchel is in sleep mode until after the release of 4.6.1. Also, I'm quite willing to go on the input of third parties but I *do* want a review before committing. As for using g_strdup() - you'd better remove the g_free() in mc_maybe_editor_or_viewer() since at the time it is called MC is already exiting so it doesn't matter so much if that memory is free or not. So the assignment of file to dir.list[0].fname is no problem as such? Anyway, I'll be applying my patch for Cygwin even if it is not approved here before the release. At least I've tried to get those changes in the proper way. Noted. As I've told you before, I'd appreciate it if you'd not address your gripes against Roland to me. We are two quite distinct persons you see. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit stackdumps on exit
Hi Pavel, On Wed, 2005-06-15 at 14:28, Pavel Tsekov wrote: If it is the oh, boy thing that upset you - I used that as expression of exclamation and I don't see anything personal in doing so. Certainly I don't call you names - this was not my intention at least. Neither did I feel it as such (name calling). However, I somewhat get the feeling that you mistake my lack of time to properly review your patch as a lack of interest in your patch or the project as such. Your response gives me the impression you feel personally neglected because of the lack of developer time and your exclamation IMO makes your response too personal. Let me make it clear that I neither have a lack of interest in the project nor in your patches. In the past I have taken time to review your patches, but excuse me that I do this when it conveniences *me*. Why testing if the bugs are not fixed ? Now this is the kind of tone that I can't appreciate. It suggests that nobody is interested in mc but you. This of course is totally untrue. You confuse the fact that I haven't (taken) time to review your patch with a rejection of and lack of interest in it. None of the three developers of MC are willing to review patches. Yet another false assumption. I've never indicated I am not willing to review your patch. And I can't speak with certainty for rillig or pchel. All I can do is indicate how I think the situation currently is. Well, guys, I have to tell you something - pack your bags and go away. (Not being personal?) Now why is that? I not having time to review patches doesn't stagnate the project now does it? It's not like I prevent others from doing it. I could understand you (the developers) if at least someone was active while the others were idle. How is that? I didn't read in the job description that I'd have to synchronise my agenda with that of the other developers. At least not in the way you are suggesting. I spent my time uncovering a bug and crafting a patch for it - and yes this is not the first time I do it. This is appreciated. If you'd think twice you'd know I do. I would expect that someone of the developers would spent some time to take a look a it, to try to understand the issue, to discuss it at least. I am discussing it. Well, was. But you seem to confuse my questions for a refusal of your patch. Well, this is kind of strange. You know that noone is willing to perform a review but you still want a review. Did I get it wrong ? Indeed. What I meant is that if none of the official developers has time to review the patch I have no objection to go on the judgement of others who frequent this list and are willing to review the patch. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit stackdumps on exit
--- [ Leonard den Ottolander ] ===--- Hi Pavel, Why testing if the bugs are not fixed ? Now this is the kind of tone that I can't appreciate. It suggests that nobody is interested in mc but you. This of course is totally untrue. You confuse the fact that I haven't (taken) time to review your patch with a rejection of and lack of interest in it. Hmm, I don't see that at all. I think it's a good question, and deserves an answer. If you're planning on a new releae of MC a week after the last rc, doesn't that mean you either A: commit to fixing any bugs found in that time, or B: should wait on the release until the bugs found are fixed? Also, nice dodge. You did a very good job of avoiding a legitimate question by making it about the person asking the question, rather than what was being asked. Now, how about answering the question? -- Regards, Scott ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit stackdumps on exit
Hi Pavel, On Tue, 2005-06-14 at 07:09, Pavel Tsekov wrote: Have you reported this issue to mitre.org or bugtraq? Nope. I didn't knew that I should do. Can you do that ? As you stated this was a serious issue I assumed you meant it to be exploitable. I have never reported such issues to mitre.org or bugtraq, but if this is indeed an exploitable issue I think we should. Please post any details if you think this issue is indeed exploitable and how. Maybe Andrew Samoilov can help us out here? Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit stackdumps on exit
Hello, On Tue, 14 Jun 2005, Leonard den Ottolander wrote: Hi Pavel, On Tue, 2005-06-14 at 07:09, Pavel Tsekov wrote: Have you reported this issue to mitre.org or bugtraq? Nope. I didn't knew that I should do. Can you do that ? As you stated this was a serious issue I assumed you meant it to be exploitable. You've assumed too much. I never said that I think that this issue is exploitable. It may be but I've never explored this possibility. Still I think that this issue is serious no matter if it is exploitable or not. Each bug which is found should be considered serious. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit stackdumps on exit
Hi Pavel, On Tue, 2005-06-14 at 16:51, Pavel Tsekov wrote: As you stated this was a serious issue I assumed you meant it to be exploitable. You've assumed too much. I never said that I think that this issue is exploitable. Yes and no. But since you're remark left some room for interpretation I inquired about the actual meaning of your words by posing my assumption (as in hypothesis). Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit stackdumps on exit
Hello, On Tue, 14 Jun 2005, Leonard den Ottolander wrote: Hi Pavel, On Tue, 2005-06-14 at 16:51, Pavel Tsekov wrote: As you stated this was a serious issue I assumed you meant it to be exploitable. You've assumed too much. I never said that I think that this issue is exploitable. Yes and no. But since you're remark left some room for interpretation I inquired about the actual meaning of your words by posing my assumption (as in hypothesis). Ok, fine. If someone is willing to investigate if this bug is exploitable that's fine. But let's not hold the patch for another couple of days/weeks/months until someone finds out if it is exploitable or not. I suggest to the reponsible parties (maintainers/developers/package maintainers) to consider the already available (or a better) patch for inclusion in MC 4.6.1. Those interested in evaluating the level of security threat posed by this bug can take their time to investigate it and post a report. At least now people are aware that a double free condition exists in MC and they can take action. P.S. I haven't investigated but I guess that this is not a new bug and it is available also in older versions of MC. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit stackdumps on exit
Hi Pavel, On Tue, 2005-06-14 at 21:36, Pavel Tsekov wrote: But let's not hold the patch for another couple of days/weeks/months until someone finds out if it is exploitable or not. I've briefly glanced at it. Can't we just add a g_strdup() for 4.6.1 and work on your improved patch for post 4.6.1? P.S. I haven't investigated but I guess that this is not a new bug and it is available also in older versions of MC. I've taken a short look at the change logs and I don't see anything indicating a change in that code for ages. Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit stackdumps on exit
Hello, On Sun, 12 Jun 2005, Leonard den Ottolander wrote: Hi Pavel, On Sun, 2005-06-12 at 19:49, Pavel Tsekov wrote: current_panel-dir.list[0].fname = (char *) file; ^ Will a g_strdup() suffice? Yes, but it is not a long term solution. I'm almost done with a patch which makes expand_format() work even if `current_panel' is not set. Stay tuned. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[PATCH] Re: mcedit stackdumps on exit
Hello,
On Mon, 13 Jun 2005, Pavel Tsekov wrote:
Hello,
On Sun, 12 Jun 2005, Leonard den Ottolander wrote:
Hi Pavel,
On Sun, 2005-06-12 at 19:49, Pavel Tsekov wrote:
current_panel-dir.list[0].fname = (char *) file;
^
Will a g_strdup() suffice?
Yes, but it is not a long term solution. I'm almost done with a patch
which makes expand_format() work even if `current_panel' is not set. Stay
tuned.
I am posting a patch for review, comments, etc. This is a candidate for mc
4.6.1. I have another patch which is more intrusive and needs much more
attention. I'll post later when I am sure it is clean enough - it
will be candidate for HEAD.
The patch includes the following changes:
1) Exports the global variable `edit_one_file'.
2) The code initializing a dummy `dir_list' entry in setup_dummy_mc() is
removed.
The argument to setup_dummy_mc() is removed since it is no longer used.
3) mc_maybe_editor_or_viewer() is rearranged to reflect the changes to
setup_dummy_mc().
3) expand_format() is changed so that it will use the `filename' member of
WEdit if the MC is started as `mcedit'. `mc_get_current_wd' will be
used to determine the current directory `mcedit' mode instead of
`panel-cwd'. Finally the code just eats the `u' and `t' format
specifiers when in `mcedit' mode.? .swp
? m4/isc-posix.m4
Index: src/main.c
===
RCS file: /cvsroot/mc/mc/src/main.c,v
retrieving revision 1.355
diff -u -p -r1.355 main.c
--- src/main.c 7 Jun 2005 20:55:13 - 1.355
+++ src/main.c 13 Jun 2005 13:24:38 -
@@ -257,7 +257,7 @@ char *command_line_colors = NULL;
static const char *view_one_file = NULL;
/* File name to edit if argument was supplied */
-static const char *edit_one_file = NULL;
+const char *edit_one_file = NULL;
/* Line to start the editor on */
static int edit_one_file_start_line = 0;
@@ -1400,21 +1400,13 @@ setup_mc (void)
}
static void
-setup_dummy_mc (const char *file)
+setup_dummy_mc ()
{
char d[MC_MAXPATHLEN];
mc_get_current_wd (d, MC_MAXPATHLEN);
setup_mc ();
mc_chdir (d);
-
-/* Create a fake current_panel, this is needed because the
- * expand_format routine will use current panel.
- */
-strcpy (current_panel-cwd, d);
-current_panel-selected = 0;
-current_panel-count = 1;
-current_panel-dir.list[0].fname = (char *) file;
}
static void
@@ -1701,27 +1693,25 @@ prepend_cwd_on_local (const char *filena
static int
mc_maybe_editor_or_viewer (void)
{
-char *path = NULL;
-
if (!(view_one_file || edit_one_file))
return 0;
+setup_dummy_mc ();
+
/* Invoke the internal view/edit routine with:
* the default processing and forcing the internal viewer/editor
*/
if (view_one_file) {
+ char *path = NULL;
path = prepend_cwd_on_local (view_one_file);
- setup_dummy_mc (path);
view_file (path, 0, 1);
+ g_free (path);
}
#ifdef USE_INTERNAL_EDIT
else {
- path = prepend_cwd_on_local ();
- setup_dummy_mc (path);
edit_file (edit_one_file, edit_one_file_start_line);
}
#endif /* USE_INTERNAL_EDIT */
-g_free (path);
midnight_shutdown = 1;
done_mc ();
return 1;
Index: src/main.h
===
RCS file: /cvsroot/mc/mc/src/main.h,v
retrieving revision 1.59
diff -u -p -r1.59 main.h
--- src/main.h 23 May 2005 16:37:02 - 1.59
+++ src/main.h 13 Jun 2005 13:24:38 -
@@ -109,6 +109,7 @@ void print_vfs_message(const char *msg,
__attribute__ ((format (printf, 1, 2)));
extern char *prompt;
+extern const char *edit_one_file;
extern char *mc_home;
char *get_mc_lib_dir (void);
Index: src/user.c
===
RCS file: /cvsroot/mc/mc/src/user.c,v
retrieving revision 1.71
diff -u -p -r1.71 user.c
--- src/user.c 27 May 2005 03:35:15 - 1.71
+++ src/user.c 13 Jun 2005 13:24:39 -
@@ -171,7 +171,7 @@ strip_ext(char *ss)
char *
expand_format (struct WEdit *edit_widget, char c, int quote)
{
-WPanel *panel;
+WPanel *panel = NULL;
char *(*quote_func) (const char *, int);
char *fname;
char *result;
@@ -180,15 +180,18 @@ expand_format (struct WEdit *edit_widget
if (c == '%')
return g_strdup (%);
-if (islower ((unsigned char) c))
+if (edit_one_file != NULL)
+ fname = edit_widget-filename;
+else if (islower ((unsigned char) c))
panel = current_panel;
else {
if (get_other_type () != view_listing)
return g_strdup ();
panel = other_panel;
}
-if (!panel)
- panel = current_panel;
+
+if (panel)
+ fname = panel-dir.list[panel-selected].fname;
if (quote)
quote_func = name_quote;
@@ -196,7 +199,6
Re: mcedit stackdumps on exit
Hi Pavel, On Mon, 2005-06-13 at 08:42, Pavel Tsekov wrote: current_panel-dir.list[0].fname = (char *) file; ^ Will a g_strdup() suffice? Yes, but it is not a long term solution. Have you reported this issue to mitre.org or bugtraq? Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit stackdumps on exit
Hello, On Mon, 13 Jun 2005, Leonard den Ottolander wrote: Hi Pavel, On Mon, 2005-06-13 at 08:42, Pavel Tsekov wrote: current_panel-dir.list[0].fname = (char *) file; ^ Will a g_strdup() suffice? Yes, but it is not a long term solution. Have you reported this issue to mitre.org or bugtraq? Nope. I didn't knew that I should do. Can you do that ? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit stackdumps on exit
Hi Pavel, On Sun, 2005-06-12 at 19:49, Pavel Tsekov wrote: current_panel-dir.list[0].fname = (char *) file; ^ Will a g_strdup() suffice? Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit stackdumps on exit
Hello, On Fri, 10 Jun 2005, [iso-8859-2] Krzysztof Dulba wrote: Hi For a few months now I've been suffering from mcedit internal error. Every once in a while, without any reason, mcedit stackdumps during exit procedure (after pressing F10 or double ESC). Debugging mcedit seems pointless as stackdumps occur on a very irregular basis. Can I provide any more information? I work on a Cygwin system, but Cygwin people told me that I should rather send this report here. I'll look into this. ___ Mc mailing list http://mail.gnome.org/mailman/listinfo/mc
Re: mcedit (allmost)dead-loop and memory leak
On Tue, Jun 24, 2003 at 08:21:09PM -0400, Pavel Roskin wrote: Can anybody with good understanding of the editor and the regular expressions comment on this? The code in question is prehistoric, i.e. it appears in the first revision on CVS. And unfortunately it is very dirty. When I tried to trace and fix one simple error in the search engine it took me two nights to do this... -- _.|._ |_ _. : Adam Byrtek /alpha [EMAIL PROTECTED] (_|||_)| |(_| : http://krakow.linux.org.pl/pgp 0xB25952C0 | ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit (allmost)dead-loop and memory leak
On Mon, 23 Jun 2003, GoTaR wrote:
http://student.uci.agh.edu.pl/~gotar/license.h
choose replace (f4) or search (f7), type $ as search string and mark it
as regular expression, press enter. Voila.
Source of problem is in ... lines.
PS. I'm not subscriber of this list.
This patch helps:
=
--- edit/editcmd.c
+++ edit/editcmd.c
@@ -1486,12 +1486,6 @@ edit_find_string (long start, unsigned c
}
else if (found_start == -1) /* not found: try next line */
break;
- else if (*len == 0) { /* null pattern: try again at next character
*/
- q--;
- buf++;
- match_bol = 0;
- continue;
- }
else/* found */
return (start + offset - q + found_start);
}
=
Now $ matches the beginning of line. Not quite correct (it should be
end of line), but still better than the current behavior.
Can anybody with good understanding of the editor and the regular
expressions comment on this?
The code in question is prehistoric, i.e. it appears in the first revision
on CVS.
--
Regards,
Pavel Roskin
___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit (allmost)dead-loop and memory leak
On Mon, 23 Jun 2003, GoTaR wrote: On Mon, Jun 23, 2003 at 20:36:15 +0400, Dmitry Semyonov wrote: Source of problem is in ... lines. I don't see any ... lines in the file. I mean everything between quotations. In this file every line is between them. You have forgotten to mention the version of mc. Default version - the newest one. Search string not found dialog is displayed almost immediately in mc-4.6.0. No dead-loops, etc. I've tried my mc-4.6.0 and these two ones: http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/binaries/RedHat/8.0/mc-4.6.0-2.i386.rpm http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/snapshots/mc-2003062221-1.i386.rpm It takes them a really long time to finish (a few minutes) and memory usage grows up (up to a few MB for this file) and doesn't shrink after exiting mcedit. Well, now I see what did you mean. Very unpleasant problem. I am able to reproduce it with mc-4.6.0-4 rpm (RedHat's one?) on another machine: Red Hat Linux release 9 (Shrike) (Linux 2.4.20-18.9) $ mc -V GNU Midnight Commander 4.6.0 Virtual File System: tarfs, extfs, cpiofs, ftpfs, fish, undelfs With builtin Editor Using system-installed S-Lang library with terminfo database With subshell support as default With support for background operations With mouse support on xterm and Linux console With support for X11 events With internationalization support On the other hand mc-4.6.0 that I compiled from official sources some time ago is working fine. Options for configure were the following: --disable-dependency-tracking --disable-nls --enable-charset --with-x Red Hat Linux release 7.3 (Valhalla) (Linux 2.4.21) $ mc -V GNU Midnight Commander 4.6.0 Virtual File System: tarfs, extfs, cpiofs, ftpfs, fish With builtin Editor Using system-installed S-Lang library with terminfo database With subshell support as default With support for background operations With mouse support on xterm and Linux console With support for X11 events With multiple codepages support ...Bye..Dmitry. ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit (allmost)dead-loop and memory leak
On Mon, 23 Jun 2003, GoTaR wrote: http://student.uci.agh.edu.pl/~gotar/license.h choose replace (f4) or search (f7), type $ as search string and mark it as regular expression, press enter. Voila. Source of problem is in ... lines. I don't see any ... lines in the file. You have forgotten to mention the version of mc. Search string not found dialog is displayed almost immediately in mc-4.6.0. No dead-loops, etc. ...Bye..Dmitry. ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit file locking
On Tue, Mar 25, 2003 at 01:59:12AM -0500, Pavel Roskin wrote: 3) System-wide locks using fcntl() or (if not supported) flock(). i'd go with that one. Pro: No stale locks. Works in non-writable directories. Locking between users. and it's simple (except the #ifdef for fcntl vs. flock). the other variants get hairy once you try to get around the stale lock problem. Con: not 100% portable, but should work on most modern systems. and it's halfways broken over nfs - at least one of the variants. check out the man page. Locks affect other software. that's a) not exactly a downside, if you ask me and b) usually not true, as the locks are only advisory, not mandatory, so the other application has to use locking itself to notice what we do. one thing to note is, that cooledit would need to keep the file open all the time. dunno if it does currently. Should the lock be held for the whole time when the file is being edited yes. that was my point in the initial request. i want a warning like this file is already being edited. still want to open it? (No/yes). or just for the time when it's being saved? that helps against corrupting the file if two instances try to write out at once, but is otherwise useless. Do we want the locks to affect other software? Do we want locks to be shared between users? it would not hurt. i don't care much, personally. With all that complexity I feel that we probably should postpone the issue or find a popular editor that used locking already and implement locking in a compatible way. hmm, and what if multiple popular editors use different approaches? :} greetings -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit file locking
On Mon, Mar 24, 2003 at 06:02:16PM -0500, Pavel Roskin wrote: What do you think is the best way to implement file locking in mc editor? I want to work on this issue, but first I want to consult you, because you know many of the portability secrets :) Why do you think we need file locking in the editor? It's not an often requested feature. What kind of scenarios do you want to prevent? Do we need write locks or read locks? I just wanted to start work on the following TODO item: Lock files in the editor to prevent opening them more than once. Warn user when opening locked file. Did I misunderstand something? Regards Adam -- _.|._ |_ _. : Adam Byrtek /alpha/ (_|||_)| |(_| : email alpha@(irc.pl|debian.org) | : jabber alpha.pl(at)jabber.org, pgp 0xB25952C0 ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit file locking
Hello, Adam! Why do you think we need file locking in the editor? It's not an often requested feature. What kind of scenarios do you want to prevent? Do we need write locks or read locks? This question still needs to be answered. I just wanted to start work on the following TODO item: Lock files in the editor to prevent opening them more than once. Warn user when opening locked file. Did I misunderstand something? No, it was me :-) OK, we have several possibilities: 1) mc-specific, user-specific file locks using O_EXCL. Lock files should probably go to /tmp/mc-$USER. Pro: Other software is not affected. Fully portable (even RCS uses it). Works in non-writable directories. Con: Stale locks may be left under /tmp/mc-$USER is mc is killed. Locking between users may be desired in some cases. 2) mc-specific, non-user-specific file locks. Created in the same directory as the file being edited. Pro: other software is not affected. Fully portable. Con: Stale locks may be left everywhere, copied together with directories. Doesn't work in non-writable directories. 3) System-wide locks using fcntl() or (if not supported) flock(). Pro: No stale locks. Works in non-writable directories. Locking between users. Con: not 100% portable, but should work on most modern systems. Locks affect other software. We can also use combinations of the above, e.g. fcntl() on file locks. If the fcntl() lock can be obtained on an existing file lock, it's assumed to be a stale lock. To make a choice, we need to answer a few questions. Should the lock be held for the whole time when the file is being edited or just for the time when it's being saved? If we take the later approach, the user will have a chance to save the file under another name in the editor that is closed last. Do we want the locks to affect other software? I just checked, support for fcntl() in vim 6.1 is planned, but it's not there yet. cooledit 3.17.6 doesn't seem to use fcntl() for locking. Most importantly, I'm not sure if we want other software (like procmail) to wait for the mc lock, even if I'm reading the mail in the editor. Do we want locks to be shared between users? Of course the locks should not be mandatory, but I'm not sure if we want e.g. root to be affected by users' locks at all. With all that complexity I feel that we probably should postpone the issue or find a popular editor that used locking already and implement locking in a compatible way. -- Regards, Pavel Roskin ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit help file
Hello, Marco! In mcedit help file: The completion key also does a Return with an automatic indent. is that true? In fact, I don't understand what it means. This sentence is prehistoric, i.e. is was present in the revision 1.1 of the document, imported into the CVS repository on February 27, 1998. The completion itself was implemented much later: 2002-01-21 Matthias Urban [EMAIL PROTECTED] * edit.c: Add support for CK_Complete_Word event. * editcmddef.h: Likewise. * edit_key_translator.c (cooledit_key_map): Bind Alt-Tab to CK_Complete_Word. (emacs_key_map): Likewise. * editcmd.c: Implement word completion. I have changed the manual so that it documents the current behavior. It's a shame than more efforts are put into translating the manuals than into making sure that they are worth translating. I really appreciate that you actually check the text you are translating. Thank you! -- Regards, Pavel Roskin ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit help file
On Fri, Sep 20, 2002 at 11:46:44AM -0400, Pavel Roskin wrote: Hello, Marco! In mcedit help file: The completion key also does a Return with an automatic indent. is that true? In fact, I don't understand what it means. I too :-P This sentence is prehistoric, i.e. is was present in the revision 1.1 of the document, imported into the CVS repository on February 27, 1998. The completion itself was implemented much later: 2002-01-21 Matthias Urban [EMAIL PROTECTED] * edit.c: Add support for CK_Complete_Word event. * editcmddef.h: Likewise. * edit_key_translator.c (cooledit_key_map): Bind Alt-Tab to CK_Complete_Word. (emacs_key_map): Likewise. * editcmd.c: Implement word completion. I have changed the manual so that it documents the current behavior. mcedit.1.in but in mc.1.in is the same. It's a shame than more efforts are put into translating the manuals than into making sure that they are worth translating. I really appreciate that you actually check the text you are translating. Thank you! No problem, translating is much difficult and error prone without a full understanding of the context, so I have to check almost for every sentence... The real problem is: 1) there are 2 files describing (more or less) the same thing (the internal editor) to keeping in sync: mc.1.in (in the internal editor section) and mcedit.1.in 2) and, more important, there is not a single reference mechanism like gettext strings for the manual: i.e. if I change something in the main /mc/doc/mc.1.in file, it's really difficult to track the changes in all the translated manuals... Sorry but I have not an answer to the problem...perhaps cutting up the manuals in pieces and merging the strings together like in po files... -- Regards, Pavel Roskin ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel -- You question the worthiness of my Code? I should kill you where you stand! Top ten reasons never to hire Klingon engineers Marco Ciampa ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit bug
Hi, Matthias! Yes, and I think that this is the big advantage of the editor. The emacs and so on are completely overloaded with features that nobody needs. I really don't know whether the word completion feature is alike. I can need it and I use it for writing C++ programs (with long constants and class names :-(), but in fact I don't use it constantly. It's sometimes a help, but on the other it also makes no trouble when it's not used. I don't know. Ok, I checked the patch and it looks very good - both the implementation (with many comments) and the convenient user interface. I have just committed it to CVS. Thank you for your contribution! I guess that somebody will request case-insensitive completion soon :-) -- Regards, Pavel Roskin ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit bug
Hi, Matthias!
I'm sorry but I've just discovered that it was the wrong command :-(
Only Do something on the tagged files doesn't work with complex
commands. The problem is located in the following line:
---
set %u; CMD=%0{Enter command};
---
I have committed the fix. Thank you for reporting the problem!
I've never thought so; I know that this is not a commercial project. And
I also know that you are sacrificing your free time when implementing
new features for it. All the more I'm impressed of the MC; there's
nothing assimilable for UNIX-like systems (in fact, even the Norton
Commander never was as powerful as the MC :-).
Not quite true. There are very few new features implemented by me. Your
thanks should be addressed to Miguel de Icaza and the old MC team who
wrote most of the code. They are listed in the AUTHORS file.
--
Regards,
Pavel Roskin
___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit bug
Hi Matthias Urban!
Sorry for responding so late. These days are consuming a lot of time of
us hackers ;-)
Anyway, about these patches in mc-menu: Since I have no authority on the
source, make sure Pavel sees to these patches also.
there is a little bug in the `mc-menu' file:
---
+ ! t t
@ Do something on the current file
CMD=%{Enter command}
$CMD ./%0f
---
This only works well for commands without additional arguments. If there
are arguments then only the command itself is assigned to CMD, but the
arguments are passed on to the shell trying to execute them as if they
would be commands. I think it better should look like this:
---
+ ! t t
@ Do something on the current file
CMD=%{Enter command}
$CMD ./%0f
---
Good work! It has indeed irritated me that inserting of ls -l output
did not produce what I expected.
What do you think about a Create patch files command in the mc-menu? I
tried the following:
I'm not sure when I should ever need this. When do you use it?
It's really tiresome to create the patch files for more than one file by
hand (maybe for a whole directory). I've offen have to do this, and I
I simply use the -r option of diff when comparing directories
Best wishes for 2002,
Steef
___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit bug
Steef Boerrigter wrote: I have to take back what I just wrote about the user menu after reading Pavels response and further investigation. Good work! It has indeed irritated me that inserting of ls -l output did not produce what I expected. This was with version 4.5.54 where the user menu did not function properly at all! Best wishes for 2002, This off course, I do not take back... ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Re: mcedit problem (2)
Hi, Andrew! What needs to be done is errno = 0. I'm committing this patch. And what about systems where errno is a function? I have never heard of such systems. There are many places where assignments to errno are used, so it should be safe. You can even find errno = 0; in the glibc-2.2.4 documnetation. The address of errno may be a result of a function call, but errno itself remains a valid lvalue, i.e. something that can stand on the left side of the assignment. -- Regards, Pavel Roskin ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit leaks file handler if safe save set
Hi, Pavel! I don't think this bug is present in 4.5.55. I disabled safe save and backups on remote VFS exactly for that reason and you reenabled it after the release: Andrew found this bug exactly in pure mc-4.5.55. If you find some minutes to think you have to understand this bug is not related to VFS. As far as I remember you disabled safe save because you wrongly guessed rename is not implemented over VFS. And there is no one word about mc_mkstemps in your messages. 2001-11-19 Andrew V. Samoilov [EMAIL PROTECTED] ... (edit_save_file): Enable safe save and backups on remote VFS. * it is used in edit/editcmd.c/edit_save_file() to generate filename for safe save. * without temporary hack below mc leaks file handlers and this/these file(s) cannot be unlinked or executed. Ok, please feel free to fix your bugs :-) You are so kindly, but it 100% YOUR BUG. And only a cup of good lipton tea made me kindly to you back today. Ok, safe save over VFS should be really disabled for this reason, but backup is ok. BTW, Andrew W. Nosenko reported undelfs is not large file compatible. There are atol is used in some places for ino_t. As far as I understand, ino_t stores the file number on the filesystem. I don't understand how it can have anything to do with large file support. Please explain. I have no access to mc sources and no time right now. Some later, ok? With best wishes, Andrew. ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Re: mcedit problem (2)
Hi, Pavel!
404 for (;;) {
405 c = fgetc (f);
406 if (c == EOF) {
407 if (errno == EINTR)
408 continue;
---
I cannot reproduce this, but it is possible if previous system call was
interrupted.
Exactly. Just add errno = EINTR in the beginning of the function and
you have the problem.
fgetc returns -1 on error and on end of file, so additional check needed.
It's interesting that info glibc (glibc-2.2.4) doesn't mention what
fgetc() returns if the call is interrupted before any single character has
been read. I would prefer not to rely on the assumption that it's EOF
(maybe it's documented somewhere else, but it's better to play safe).
I've also tried to reproduce this w/o success. I think we need to call
clearerr(_unlocked?) on line 408 above. (If found some usenet posts that
indicated that this is indeed necessary on Solaris. (Sorry, I that was
last week and I didn't save them.))
Actually, clearerr() would clear the EOF state from the descriptor, which
would not help.
What needs to be done is errno = 0. I'm committing this patch.
And what about systems where errno is a function?
Regards,
Andrew.
___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit problem (2)
On Friday, December 21, 2001 at 18:23, Pavel Roskin wrote:
Hi, Bj?rn!
404 for (;;) {
405 c = fgetc (f);
406 if (c == EOF) {
407 if (errno == EINTR)
408 continue;
---
I cannot reproduce this, but it is possible if previous system call was
interrupted.
Exactly. Just add errno = EINTR in the beginning of the function and
you have the problem.
The right fix is really this:
for (;;) {
c = fgetc(f);
if (c == EOF) {
if (ferror(f) errno == EINTR)
continue;
fgetc only changes errno if there's an error. Even if errno != 0, prior to
calling fgetc, fgetc won't change it. The only way to check for an error
is to use ferror(f). If ferror(f) is true then errno has been updated as
well.
Regards,
Oskar Liljeblad ([EMAIL PROTECTED])
___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit bug
Hi, Matthias!
@ Do something on the current file
CMD=%{Enter command}
$CMD ./%0f
---
This only works well for commands without additional arguments. If there
are arguments then only the command itself is assigned to CMD, but the
arguments are passed on to the shell trying to execute them as if they
would be commands. I think it better should look like this:
Could you please give an example? I tried ls -al and it works as one
would expect.
It's really tiresome to create the patch files for more than one file by
hand (maybe for a whole directory). I've offen have to do this, and I
really missed a menu command doing it for me. I know, the above command
is not the best solution. What do you think about it? I guess it could
be usefull for others, too.
I don't think this functionality needs to be tied to MC. I don't think
there are many reasons for that process to be interactive.
It's getting offtopic, but you could try this script:
===
#! /bin/sh
: ${backup_suffix=v0}
backup_files=`find . -name *.$backup_suffix -type f | sort | uniq`
for oldfile in $backup_files; do
newfile=`echo $oldfile | sed 's,^\./,,;s,\.'$backup_suffix'$,,'`
oldlabel=$oldprefix$newfile
newlabel=$newprefix$newfile
find $oldfile ! -size 0 | grep . /dev/null || \
{ oldfile=/dev/null; oldlabel=/dev/null; }
find $newfile ! -size 0 | grep . /dev/null || \
{ newfile=/dev/null; newlabel=/dev/null; }
case $newfile in
*.c) dflags=-u -p ;;
*ChangeLog*) dflags=-u1 ;;
*) dflags=-u ;;
esac
diff $dflags -L $oldlabel -L $newlabel $oldfile $newfile
done
===
Just set backup_suffix to your preferred value. You can also look at CVS
Utilities: http://www.red-bean.com/cvsutils/
--
Regards,
Pavel Roskin
___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit problem (2)
Hi, Mattias!
Hi,
is the following problem known? Sometimes (usually a few times a day :-(
) if I press F4 to edit a .cc file with the internal editor, the
Midnight Commander hangs up. Here is the description of the problem:
I cannot reproduce this, but it is possible if previous system call was
interrupted.
fgetc returns -1 on error and on end of file, so additional check needed.
---
404 for (;;) {
405 c = fgetc (f);
406 if (c == EOF) {
407 if (errno == EINTR)
408 continue;
---
It tries to read my own `c.syntax' (see the attachment). `c' and `errno'
always have the same values: c is -1 and errno is EINTR. `f' has the
following value (produced with `p *f' in the gdb):
Does patch below help you?
Regards,
Andrew.
--- syntax.cWed Nov 28 17:17:37 2001
+++ syntax.c-1.19+ Mon Dec 17 10:09:15 2001
@@ -405,6 +405,8 @@ static int read_one_line (char **line, F
for (;;) {
c = fgetc (f);
if (c == EOF) {
+ if (feof (f))
+ break;
if (errno == EINTR)
continue;
r = 0;
Re: mcedit problem (2)
[Please excuse my editing]
On Mon, Dec 17, 2001 at 10:33:13AM +0200, Andrew V. Samoilov wrote:
is the following problem known? Sometimes (usually a few times a day :-(
) if I press F4 to edit a .cc file with the internal editor, the
Midnight Commander hangs up. Here is the description of the problem:
---
404 for (;;) {
405 c = fgetc (f);
406 if (c == EOF) {
407 if (errno == EINTR)
408 continue;
---
I cannot reproduce this, but it is possible if previous system call was
interrupted.
fgetc returns -1 on error and on end of file, so additional check needed.
I've also tried to reproduce this w/o success. I think we need to call
clearerr(_unlocked?) on line 408 above. (If found some usenet posts that
indicated that this is indeed necessary on Solaris. (Sorry, I that was
last week and I didn't save them.))
[I've done OS-/embedded-stuff all my life so I'm not very good at
user-space things.]
Some quotes from libc.info:
Error Recovery
...big snip...
Most errors that can happen are not recoverable -- a second try will
always fail again in the same way. So usually it is best to give up and
report the error to the user, rather than install complicated recovery
logic.
...small snip...
One important exception is `EINTR' ( Interrupted Primitives). Many
stream I/O implementations will treat it as an ordinary error, which
can be quite inconvenient. You can avoid this hassle by installing all
signals with the `SA_RESTART' flag.
Does patch below help you?
--- syntax.c Wed Nov 28 17:17:37 2001
+++ syntax.c-1.19+Mon Dec 17 10:09:15 2001
@@ -405,6 +405,8 @@ static int read_one_line (char **line, F
for (;;) {
c = fgetc (f);
if (c == EOF) {
+ if (feof (f))
+ break;
if (errno == EINTR)
continue;
r = 0;
I don't think so but either way we need some code up that can test it
(EINTR), perhaps a timer?
--
//Björnen
msg00429/pgp0.pgp
Description: PGP signature
Re: Re: mcedit bug
[TO THE MODERATOR: Dear Pavel, as a matter of fact the mail to Bjoern
wasn't meant to be sent to the list. It was a carelessness of me. I'm
sorry.]
Hi Steef,
Well, indeed, I know what you mean and for these cases I usually hold a
shift button and grab for the mouse to fall back to the good old X/gpm
cutpaste.
Oh, this works? I never tried to hold down the shift key. (how
embarrassing :-)))
not be able to deal with the SHIFT-INS. The only reason may be that
CTRL-INS can store multiple lines, whereas the entry fields would
normally close when they receive a newline. These normally need to be
Yes, that's true. But gpm`s copy mechanism can store multiple lines too.
You see, the problem is already there. Moreover, gpm running on the
virtual consoles isn't a matter of course, though it should be. For
instance the Linux distribution I'm using (SuSE) was configured to not
start gpm if xdm is also started! I don't know the reason for this
behavior (and I've changed it the day I became aware of it ;-), but that
might be not a rarity I guess.
Best regards,
Matthias
PS: Did you read the mail about the problem I had with `c.syntax'? There
I forgot to mention that I had this problem not only with the new
Midnight Commander (4.5.99a). At the moment the Commander I use doesn't
try again reading a character if there was an interrupt ('if (errno =
EINTR) continue;' commented out). This can only be a work around since I
also know that it is explicitly allowed and recommended to try a system
call again if it was interrupted. But, is it a good idea to try it
endlessly? I've no idea who is interrupting the read process, so I'm
also not able to estimate the problem :-(
___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Re: mcedit bug
Hi Steef, --- ex +:s/.*/\U/g +:w! outputfile +:q inputfile --- A, this stuff looks beautiful. And it might be the better choice in the future; I've read that the coming versions of `vim' (=ex) shall be able to match even multi-lines (including newline matching). For the `vim' developers it seems to have the priority as soon as possible (is there already a version 6 of `vim'? I don't know). No, I abandoned emacs completely in about 1993... I found it a bit overdone to have an editor of more than 30Megs .tar.gz! This is sooo true, and more: I've not changed the OS from Windows to Linux only to replace my Windows click-tools with a Linux click-tool. Under Windows it wasn't fast enough and flexible enough for me already, and the emacs --- it isn't more than ever. However, it's not long ago I saw a friend editing a XML file with the emacs and he just typed in `Des', pressed a key (or more, I don't know), and the word became completed (=`Description'). Since then I also wanted to have this feature in the Midnight Commander ;-) Moreover, I once tried to redefine my keys in emacs to get a working insert,home,end,page up and so on. Need I say more? Ok, one word: LISP! Crepy! I am in the process of writing my Ph.D. thesis. In my field of science, looong complicated words are not helping the reader, is my experience. (Thesis, wow! I'm only just writing my diploma :-( ) Your idea sounds great though. And you should off-course be able to search the user-dict files like ~/.ispell_english. Ooh, THIS is good. It's like the kind of help you got when writing a SMS with your handy (I don't write SMSs because my handy doesn't has this feature --- and I still wanna be able to use my fingers for a while ;-) Moreover, it's an easy and fast way to lookup a word in the dictionary, in contrast to the dictionary in your hand. And, it's not a replacement for the `ispell'-check, but a good enhancement. And now to something completely different... What do you think about the following: If you're editing a source file and you want to find or replace something, you have to type in the expression you want to find at the `search' or `replace' window. That's true, isn't it? But sometimes the text is hidden by the `search' or `replace' window; then you have to close it, to scroll the text or to note the text somewhere, and then you can start from scratch. And what's about complicated expressions like `MultiLevelStackSemanticObject*' or `(PtrType*)((*(ThisType*)ptr).conv ())'? Typing this in isn't very amusing. So, why can't I use CTRL-INS to copy the text I want to find to `cooledit.clip' and then use SHIFT-INS in the `search'/`replace' window to paste this text? I offen have this problem and I think that this could be a useful improvement (above all, it shouldn't be very hard to implement ;-). What do you mean? By the way, I'm also using the Midnight Commander to write my mails. To mark the text of the mail I'm replying to, the following user menu command is very useful: --- pprefix TEMPFILE=$(dirname %b)/cooledit.temp sed -e s@.*@ @g %b $TEMPFILE cat $TEMPFILE %b --- Very simple, but it works fine. Ok, the name is crap, but I don't know a better one. Do you? Bye, Matthias ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit bug
Hi Steef,
By the way, optimally, I would like it to add something like this:
#if FAST_COPY_TECHNIQUE
.
.
.
#endif /* FAST_COPY_TECHNIQUE */
where FAST_COPY_TECHNIQUE is given as the argument of the user
function.
This is quite better, of course. By the way, what do you think about the
`turn to uppercase' command? Ok, it is designed for german, but there is
also a problem: `sed' doesn't know `\U' (turn to _U_ppercase) in
contrast to `ex'. And `awk' has a function `toupper()'. But only `sed'
seems to handle the input as a stream, so that newlines can be part of a
match. The problem is, that using `ex' or `awk' always results in a
trailing newline or newlines are cutted :-(. The `awk' script would look
about like this:
---
awk { print toupper($0); } inputfile
---
and the `ex' script like this:
---
ex +:s/.*/\U/g +:w! outputfile +:q inputfile
---
Does you know a better solution than the `sed' script? Because I really
think that `turn to uppercase' is a useful thing.
No, it's better to insert a newline, but only if the cursor is not on
the start of the line. The problem is, that you cannot know this from
the $TEMPFILE
...
Exactly! This should work. However, if started on empty lines, there
will be a couple of unnecessary empty lines.
Also, putting them in, is easy. But how do you get the extra \n's out?
There is off course no telling whether the original file had these extra
\n's
That's right, I also saw this problem, and I think that inserting a
newline
if the cursor is not on the start of a line is the best solution,
because on the other hand, removing an unwanted newline should be no
problem for the user ;-)
PS: Is `word completion' within the editor a subject for you at all?
? what do you mean by `word completion` do you mean that when I type
retALT-TAB
I get
return
when editing c-files?
Nearly, I rather mean names of functions, variables, classes etc. than
keywords; in fact, every word _I wrote_ (and not only in .cc files),
like the emacs does, you know!? Example: Somewhere in the document
(above my current position) there is a function `void
resolve_function_name ()' and now I want to insert a call to it at the
current position. But the name of the function is so long, so that I
type in the first characters of the function name and press ALT-TAB
and the word is completed, and I am happy :-). I think, you don't need a
database of the words I wrote; a search about the text from the current
position to the start of the document (maybe in this direction?) should
be enough (like a `grep resol*'). What do you think? I think it could
be also a good feature when writing a scientific paper with lots of
looong complicated words :-)
Best regards,
Matthias Urban
___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit bug
Matthias,
first, thanks for your quick answer. And you are right; C style comments
can be quite problematic. But using conditional preprocessor directives
can cause quite similar problems; just imagine there is a single #if or
#ifdef inside the block you want to hide! By the way, only C++ style
comments really seem to be completely problem-free :-(
That situation is rather rare. At least much less common than finding a
single commentline.
By the way, optimally, I would like it to add something like this:
#if FAST_COPY_TECHNIQUE
.
.
.
#endif /* FAST_COPY_TECHNIQUE */
where FAST_COPY_TECHNIQUE is given as the argument of the user
function.
But that wasn't quite the problem I had. Do you really mean that it's
the better way to hard-code moving the cursor to the beginning of the
line than to leave this decision to the user? You wrote:
No, it's better to insert a newline, but only if the cursor is not on
the start of the line. The problem is, that you cannot know this from
the $TEMPFILE
I don't think that this is a problem. I would (and have :-) implement it
like this:
---
+ f \.h$ | f \.c$ | f \.cc$ | f \.C$ | f \.H$ | f \.cpp$
6 #if 0 ... #endif
TEMPFILE=$(dirname %b)/cooledit.temp
echo -e \n#if 0 $TEMPFILE
cat %b $TEMPFILE
cat $TEMPFILE %b
echo -e \n#endif %b
---
Exactly! This should work. However, if started on empty lines, there
will be a couple of unnecessary empty lines.
Also, putting them in, is easy. But how do you get the extra \n's out?
There is off course no telling whether the original file had these extra
\n's
PS: Is `word completion' within the editor a subject for you at all?
? what do you mean by `word completion` do you mean that when I type
retALT-TAB
I get
return
when editing c-files?
If that's what you mean, perhaps
Not for c-files though. I defined macros to enter standard clauses like
these:
ALT-I
gives
if ()
{
}
else
{
}
However, it may be practical for other file-types. I really think it
should be a filetype-specific functionality. I don't need to complete
the word return in this mail. Although, I used the word return quite a
lot in this mail already ;-)
Steef
___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Re: mcedit bug
Hi Steef, first, thanks for your quick answer. And you are right; C style comments can be quite problematic. But using conditional preprocessor directives can cause quite similar problems; just imagine there is a single #if or #ifdef inside the block you want to hide! By the way, only C++ style comments really seem to be completely problem-free :-( But that wasn't quite the problem I had. Do you really mean that it's the better way to hard-code moving the cursor to the beginning of the line than to leave this decision to the user? You wrote: Of course, the #if/#endifs should always start at a new line, which may be difficult to implement. I don't think that this is a problem. I would (and have :-) implement it like this: --- + f \.h$ | f \.c$ | f \.cc$ | f \.C$ | f \.H$ | f \.cpp$ 6 #if 0 ... #endif TEMPFILE=$(dirname %b)/cooledit.temp echo -e \n#if 0 $TEMPFILE cat %b $TEMPFILE cat $TEMPFILE %b echo -e \n#endif %b --- For the user (or the programmer of the editor user menu ;-) it is always possible to insert a newline (as you can see above); it stays an option. But if it's hard-coded (as it is in the moment), it's no more an option; for the user there is NO way to suppress it. I really think that there are a lot of use cases where this is a problem. Here is another example (something I'm gonna use more and more): Imagine you're editing a text and you want to highlight a sentence or more containing something very important (maybe copyrights ;-) by turning it to uppercase. The user menu command may look like this (common section): --- u turn to uppercase TEMPFILE=$(dirname %b)/cooledit.temp LOWER=abcdefghijklmnopqrstuvwxyzäöü UPPER=ABCDEFGHIJKLMNOPQRSTUVWXYZÄÖÜ sed -e y/$LOWER/$UPPER/ %b $TEMPFILE cat $TEMPFILE %b --- And you can imagine that not all sentences you want to highlight start at the beginning of a line. Example: Applying the `turn to uppercase' command to the second sentence of the following text --- To determine the scope of a declaration, it is some- times convenient to refer to the potential scope of a declaration. The scope of a declaration is the same as its potential scope unless the potential scope contains another declaration of the same name. In that case, the potential scope of the declaration in the ... --- results in the following: --- To determine the scope of a declaration, it is some- times convenient to refer to the potential scope of THE SCOPE OF A DECLARATION IS THE SAME AS ITS POTENTIAL SCOPE UNLESS THE POTENTIAL SCOPE CONTAINS ANOTHER DECLARATION OF THE SAME NAME.a declaration. In that case, the potential scope of the declaration in the ... --- This is entirely unacceptable, isn't it? It should (and does exactly with the changes in `edit.c') look like this: --- To determine the scope of a declaration, it is some- times convenient to refer to the potential scope of a declaration. THE SCOPE OF A DECLARATION IS THE SAME AS ITS POTENTIAL SCOPE UNLESS THE POTENTIAL SCOPE CONTAINS ANOTHER DECLARATION OF THE SAME NAME. In that case, the potential scope of the declaration in the ... --- Ok, that's all (and `CRTL-o' within the editor is divine :-))) Matthias PS: Is `word completion' within the editor a subject for you at all? ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: mcedit bug
Hi Matthias,
I like your idea.
if (type-isFunction()) {
return new FunctionInfo(type);
} /*else if (type-isClass()) {
return new ClassInfo(type);
} */else {
return new ErrorInfo(type);
}
However, I always use #if /#endif constructions, which prevents the
nested comment problem, which also works for these cases:
if (type-isFunction()) {
return new FunctionInfo(type);
} else if (type-isClass()) {
/* this is a comment */
return new ClassInfo(type);
} else {
return new ErrorInfo(type);
}
becomes:
if (type-isFunction()) {
return new FunctionInfo(type);
}
#if 0
else if (type-isClass()) {
/* this is a comment */
return new ClassInfo(type);
#endif
} else {
return new ErrorInfo(type);
}
An other advantage is, that you can reenable the line by simply changing
the 0 in a 1:
#if 0
becomes
#if 1
Of course, the #if/#endifs should always start at a new line, which may
be difficult to implement.
What do you think about that idea?
Regards,
Steef
___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel
